-
Notifications
You must be signed in to change notification settings - Fork 955
extend stdlib to allow import of more packages #1099
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This PR conflicts with #1012, which I think should be merged first as it also cleans up the os package a bit. |
) | ||
|
||
func IsPermission(err error) bool { | ||
return err == ErrPermission |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not complete (it doesn't unwrap the error) but I guess it's fine for now.
// Lookup returns the value associated with key in the tag string. | ||
func (tag StructTag) Lookup(key string) (value string, ok bool) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Get and Lookup will need tests. Please add them to testdata/reflect.go. You can probably just try to lookup a few tags and if they are present, print them (just like many other properties of types/values are printed).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it may be better to use something other than a string for StructTag
eventually. The last time I looked through the standard library, no package was using StructTag
as a string but instead just called the Get
and Lookup
functions. Therefore, I think it would be feasible to do the key/value splitting at compile time, avoiding the code size cost of doing it at runtime (and possibly speeding things up as well, although that's not the goal).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure you actually need Get
and Lookup
? You could perhaps simplify things by stubbing them out. At least when I tested the encoding/json package, I think I managed to do without for a proof-of-concept.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the StructTag
type with it's functions is actively used in common libraries github.com/BurntSushi/toml
and gopkg.in/yaml.v2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added your proposal to do it at compile time as a TODO comment. For this MR i focused on getting more libraries to compile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked both libraries.
github.com/BurntSushi/toml
passes the.Tag
field as aStructTag
togetOptions
and only uses the.Get
function. That would allow doing the key/value parsing at compile time.gopkg.in/yaml.v2
unfortunately does use the raw string. It looks like they fall back to using the whole string if the struct tag is not in a key/value format. I think they shouldn't do this as it breaks the convention, but it's probably hard to persuade them to change this (there is probably code that depends on this behavior).
Not sure what to do here, maybe using raw strings is better after all (even though it will likely increase code size). Maybe there are optimizations possible here, but I'm not sure whether that's possible in a sane way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you write this code yourself or did you copy it? If you copied it, it should have a copyright note (just like the strconv.go file).
@aykevl i updated the PR |
@aykevl any further feedback? Seems like all of the comments have been addressed. |
Reminder to @aykevl about this PR. LGTM. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this PR!
For the next time, please split it up a bit more so that the changes are a bit more focused. This helps with review and with investigating regressions (if there are any).
src/reflect/strconv.go
Outdated
) | ||
|
||
// ErrSyntax indicates that a value does not have the right syntax for the target type. | ||
var ErrSyntax = badSyntax{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file adds a number of exported symbols. Because this is the reflect package, these (copied) symbols should not be exported.
// Lookup returns the value associated with key in the tag string. | ||
func (tag StructTag) Lookup(key string) (value string, ok bool) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you write this code yourself or did you copy it? If you copied it, it should have a copyright note (just like the strconv.go file).
src/runtime/mprof.go
Outdated
package runtime | ||
|
||
// Stack is a stub, not implemented | ||
func Stack(buf []byte, all bool) int { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could add this to stack.go, which has similar functions (to avoid yet another small file).
None of these are likely to be implemented considering what TinyGo is designed for.
do not export strconv functions in reflect
@aykevl comments are addressed, I will split it up next time. |
Thank you very much for working on this contribution, @cornelk now that all of the comments have been addressed, I am going to squash/merge. Thanks again! |
The tests previous passed, but now the CI fails for all Linux platforms. Perhaps rebasing again against We now need to fix this right away. |
Thanks to @jaddr2line root problem was discovered (of course unrelated to this PR) and I just pushed a fix to the CircleCI build. |
Closes #752
these changes allow a successful import of the following go 1.14 stdlib packages: