cmd/go/internal/load: (Optionally) follow symlinks referenced by //go:embed #59924
Labels
GoCommand
cmd/go
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
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
)?N/A, applies to any GOOS/GOARCH
What did you do?
In a Bazel build action running in a symlink-based sandbox, try to build the Go standard library or any third-party package using
//go:embed
.What did you expect to see?
The build passes just as it would if the input files weren't symlinks. Tools only play nice with Bazel if they follow symlinks, as whether or not an input file to a Bazel build action is a symlink depends on the particular strategy with which Bazel chooses to execute the action (e.g. remotely or locally, in a sandbox or not, ...).
//go:embed
not allowing symlinks to be embedded makes sense and I am not asking for that to be changed. However, it would be very helpful if it could be made to follow symlinks, either by default or optionally, guarded by a flag or environment variable.What did you see instead?
This happens because of the use of
Lstat
ingo/src/cmd/go/internal/load/pkg.go
Line 2139 in 3c46d8f
go/src/cmd/go/internal/load/pkg.go
Line 2170 in 3c46d8f
This issue requires rules_go to copy around the stdlib and breaks build actions that operate on generated code.
The text was updated successfully, but these errors were encountered: