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 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.
func EmbedPatterns(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.
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:embeddirectives 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
readGoInfofunction.Note that this API doesn't return the locations of the
go:embedpatterns. I think that is OK in practice because it's easy for the developer to search for the relevantgo:embeddirective if there is an error locating the files. But if it seems appropriate we could add offset/line/column information to the results.