You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While most Go programmers use the go tool, there are alternative build systems such as Bazel. In order to build existing Go code, those build systems have to analyze go:embed directives in the same way as the go tool does. This can in principle be done by parsing the file and looking at the comments, but this permits unanticipated deviations from what the go tool does. The go/build package already contains the code that does this for the go tool, but it is not exposed in a usable form; it is only exposed as part of creating a go/build.Package, but that assumes that directory layout used by the go tool but not by Bazel.
I propose that we add a new exported method to go/build similar to a subset of the existing readGoInfo function.
// EmbedPatterns returns the patterns for all go:embed directives found in the Go file read from f.// If f does not import the "embed" package, EmbedPatterns will not return any patterns.funcEmbedPatterns(f io.Reader) []string
Note that this API doesn't return the locations of the go:embed patterns. I think that is OK in practice because it's easy for the developer to search for the relevant go:embed directive if there is an error locating the files. But if it seems appropriate we could add offset/line/column information to the results.
The text was updated successfully, but these errors were encountered:
This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group
This is similar to #52222.
While most Go programmers use the go tool, there are alternative build systems such as Bazel. In order to build existing Go code, those build systems have to analyze
go:embed
directives in the same way as the go tool does. This can in principle be done by parsing the file and looking at the comments, but this permits unanticipated deviations from what the go tool does. The go/build package already contains the code that does this for the go tool, but it is not exposed in a usable form; it is only exposed as part of creating ago/build.Package
, but that assumes that directory layout used by the go tool but not by Bazel.I propose that we add a new exported method to go/build similar to a subset of the existing
readGoInfo
function.Note that this API doesn't return the locations of the
go:embed
patterns. I think that is OK in practice because it's easy for the developer to search for the relevantgo:embed
directive if there is an error locating the files. But if it seems appropriate we could add offset/line/column information to the results.The text was updated successfully, but these errors were encountered: