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
x/tools/packages: analysis fails completely if a module version cannot be determined #40187
Comments
Can you please provide a simple reproduction that has more detail? It’s unclear what you mean by “broken modules” and saying “An error” is also quite cryptic. Thanks. /cc @matloob |
Any time modules cannot be resolved, such as with private modules or the following:
Running
This is probably because this is the behavior of |
Maybe I'm missing all the details, but this seems to be working as intended? In general, loading packages depends on getting the dependencies for the packages being analyzed. If we can't fetch the modules in the dependency tree, we can't get the build list and determine what gets built, which in turn means that we can't do the build. There might be a way around this if you just want to determine the set of files in a package with the appropriate flags to load (no export data, type information, etc.), but even that is difficult and error-prone. |
Building on what @matloob said, a working I'm not sure I understand the motivation here. Why is it important that this work when |
I only reported this as a bug because it's a regression from pre-module behavior, which would still give you partial information about the dependencies that were resolved. In this case deleting the |
We use |
Okay, thanks for the context. This use case is unfortunately in the category of being difficult enough to support that the effort required to support it wouldn't be worth the gains: we'd have to make major changes to cmd/go to try to continue working even if module loading fails and those changes wouldn't be justified by this use case. One option you could take if you want incomplete data would be to use the I'm going to close this as "unfortunate". |
That's understandable. I think the workaround should work well enough for our use-case (and frankly if somebody wants full analysis they should figure out their builds anyway...). Thanks! |
Glad to hear that the workaround should work. Thanks for the feedback! |
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Try to run tools/packages.Load on any source package that has broken modules.
What did you expect to see?
Some, albeit incomplete, information, especially AST for files that are in the package (and can be resolved).
What did you see instead?
An error.
The text was updated successfully, but these errors were encountered: