x/tools/go/packages: support for fake GOROOTs #69824
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
This issue is the continuation of discussions in CL 615396.
When I tried to migrate x/tools/go/ssa/interp away from the deprecated loader package in its test cases in CL 615016, I attempted to create a fake GOROOT with some mocked std libs so
packages.Load
could load the faked std libs, which will be complemented by thego/ssa/interp
interpreter later.Even though @adonovan has provided a better approach to use overlay and custom GOROOT in
x/tools/go/ssa/interp
doesn't make sense, however, there isn't a conclusion regarding "whether we should support the usage of fake GOROOTs." Probably we can discuss here more about whether we should support/recommend the usage of fake GOROOTs.For me, I have tried to add some libraries with my own toolchain under GOROOT because I want to use internal std package features but do not want to use the go linkname directive (which is locked down in 1.23 and higher versions, #67401).
The second point to discuss (related to the custom GOROOT) is whether it's desirable for users to add new packages under GOROOT and let the compiler treat them as standard libraries as well?
@timothy-king @matloob @adonovan
The text was updated successfully, but these errors were encountered: