Allow generating export files for the stdlib.
What type of PR is this?
Feature
What does this PR do? Why is it needed? By default, rules_go only generates Export files for the code it compiles using bazel, but not the stdlib. This is problematic for tools like golangci-lint that has analyzers that utilize the export files for their checks, including the stdlib.
It's possible to generate export files for the stdlib by passing the -export flag to the go list command, however, it comes with a time penalty (about 20s with the flag vs 2s without the flag).
Therefore, add it as an option for go_register_toolchains.
Now, you can do something like:
go_register_toolchains(
exports_for_stdlib = True,
version = "1.20.1",
)
And it will generate the export files in the stdlib.pkg.json. Note that this time penalty only seems to be when using gopackagedriver not for regular builds. Another note is that it does change the existing behavior for the ExportFile field in the gopackagedriver output because it will no longer output an incorrect ExportFile for the stdlib (don't know if anyone was depending on that feature, because pkg.Target is always empty).
Which issues(s) does this PR fix?
Fixes #3651
ps: Will add/fix tests if this approach seems sensible.
@JamyDev Could you take a look at this?
If we add this new functionality, it would be great if we could also expose it to Bzlmod users. For example, we could add a config tag to the go_sdk extension to configure this globally for all SDKs.
@fmeum @JamyDev Any update here? If the approach is viable, I can go ahead and add/fix tests.
I totally lost track of this. If it's optional and can be enabled on the fly I think this is a fine approach.
Anything I can do to help this along? I'd love to get golangci-lint working with rules_go!
I have also found this fix to be useful for getting golangci-lint working with the bazel package manager. I arrived at the exact same patch outlined here: https://github.com/bazelbuild/rules_go/issues/3651
Sorry I've been occupied. Let me rebase and clean up this PR some time next week. The main missing piece is bzlmod support. Our project hasn't migrated to it yet so it wasn't a priority and the hacky patch is much smaller than this one so it wasn't too burdensome to carry for us.