-
Notifications
You must be signed in to change notification settings - Fork 18k
go/packages: returned packages are in incorrect order #30826
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
Comments
The input to Load is "patterns", and the documentation says "in general it is not possible to determine which packages correspond to which patterns" |
That's unfortunate. I guess I understand. It's a cumbersome and expensive way to resolve a relative path. I might be remembering the order-preservation promise from go/loader. |
Prior to this change, go-fuzz-build assumed that the first package in the slice returned by packages.Load corresponded to the package requested by the user. This assumption was faulty, although it worked accidentally. This change adds another package.Load call to explicitly resolve the package to be fuzzed, and does more careful validation of it. While we're here, do some minor cleanup: * Request cheaper loading of std. All we need is package paths. * Simplify processing of the result of loading std. * Store the fuzz package, rather than its package path, in Context. This will be helpful in other planned work (e.g. adding fuzz.F). Updates golang/go#30826 and golang/go#30828
Prior to this change, go-fuzz-build assumed that the first package in the slice returned by packages.Load corresponded to the package requested by the user. This assumption was faulty, although it worked accidentally. This change adds another package.Load call to explicitly resolve the package to be fuzzed, and does more careful validation of it. While we're here, do some minor cleanup: * Request cheaper loading of std. All we need is package paths. * Simplify processing of the result of loading std. * Store the fuzz package, rather than its package path, in Context. This will be helpful in other planned work (e.g. adding fuzz.F). Updates golang/go#30826 and golang/go#30828
Prior to this change, go-fuzz-build assumed that the first package in the slice returned by packages.Load corresponded to the package requested by the user. This assumption was faulty, although it worked accidentally. This change adds another package.Load call to explicitly resolve the package to be fuzzed, and does more careful validation of it. While we're here, do some minor cleanup: * Request cheaper loading of std. All we need is package paths. * Simplify processing of the result of loading std. * Store the fuzz package, rather than its package path, in Context. This will be helpful in other planned work (e.g. adding fuzz.F). Updates golang/go#30826 and golang/go#30828
Using Go 1.12.
When I run this, I get:
I expected:
Load
is documented to return the packages in the order they were passed toLoad
. (And this is important; if given relative package names, I have no other way of correlating them to the packages I receive back fromLoad
.)This does not reproduce if
Mode
isLoadFiles
; it reproduces with all other modes.cc @matloob
The text was updated successfully, but these errors were encountered: