-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
cmd/go: list -compiled fails to populate CompiledGoFiles when the resulting package cannot be linked #34229
Comments
That is #26755.
That's a subset of #29666, I think? But we can leave this issue open as a specific instance to address. (CC @jayconrod) |
We should certainly prioritize a fix for #26755, which is what breaks static analysis. Let's make this issue about the “slower than necessary” part — I agree that it would be nice to avoid the unnecessary work, but I don't think that's likely to happen for 1.14. |
These issues are certainly related, but even if both #26755 and #29666 were fixed, this issue wouldn't be fixed. #26755 is about #29666 is related only insofar as it, too, wants to improve the performance of I regret bringing up performance in the first place, because this issue is also one of correctness, in its own right. Currently, to compute CompiledGoFiles, |
Ah, I see. Will update and retag accordingly. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?Linux, amd64
What did you do?
Create a package with the following contents:
Run
go list -json -x -compiled
on the packageWhat did you expect to see?
No errors, no attempted linking of object files, complete JSON output (meaning CompiledGoFiles is populated).
What did you see instead?
That is, Go actually attempts to build the package and fails due to the missing library we're trying to link against. It also doesn't populate CompiledGoFiles, even though cgo preprocessing succeeded.
As I understand it, this is trying to do more work than is necessary. It also unnecessarily fails.
The
-compiled
flag is documented as follows:It does not imply actual compilation. Also note that we're not passing the
-exported
flag. Furthermore, in order to do cgo processing, we do not need the linker. For that, looking at headers suffices, andgo tool cgo foo.go
does succeed.After a cursory look at cmd/go/internal/work/exec.go, (*Builder).build, it seems that if we require CompiledGoFiles, and they can't be found in the cache, we execute the full cgo pipeline used for building. In theory, it should be possible to optimize this.
The current behavior is problematic for two reasons, from the point of view of tools that analyze Go code:
/cc @matloob @ianthehat @bcmills
The text was updated successfully, but these errors were encountered: