cmd/go: error from 'go mod vendor' missing import stack for unmatched 'go:embed' pattern

[thanm]

What version of Go are you using (go version)?

$ go version
go version devel go1.18-73a4bbb0df Thu Nov 11 17:18:13 2021 +0000 linux/amd64

Does this issue reproduce with the latest release?

I tried 1.17 and it seems to have the same problem.

What operating system and processor architecture are you using (go env)?

amd64/linux

What did you do?

For this program:

https://play.golang.org/p/eXki7fZlkkc

if you download it and run "go mod vendor"

What did you expect to see?

Successful "go" cmd.

What did you see instead?

Got:

go mod vendor
go: downloading github.com/go-delve/delve v1.7.2
go: downloading golang.org/x/arch v0.0.0-20190927153633-4e8777c89be4
go: downloading github.com/sirupsen/logrus v1.6.0
go: downloading github.com/aquasecurity/libbpfgo v0.1.2-0.20210708203834-4928d36fafac
go: downloading golang.org/x/sys v0.0.0-20210514084401-e8d321eab015
go: downloading github.com/konsorten/go-windows-terminal-sequences v1.0.3
go mod vendor: pattern trace_probe/trace.o: no matching files found

Note the last error ("no matching files found"). Exit status is 1.

[seankhliao]

the file doesn't exist: https://github.com/go-delve/delve/tree/v1.7.2/pkg/proc/internal/ebpf/trace_probe

Note: delve appears to have switched ebpf libraries last week which should resolve the issue? go-delve/delve#2771

[bcmills]

We should still have a clearer diagnostic in this case, though: no matching files found doesn't explain why we were trying to match that pattern in the first place.

(I'm guessing maybe it's from a //go:embed directive, but in that case we really ought to display the import stack up to the file containing the unmatched directive.)

[bcmills]

Indeed, here is the unmatched //go:embed:
https://github.com/go-delve/delve/blob/2adb72d05373c119b76ed6b4b7a631d8268b0134/pkg/proc/internal/ebpf/helpers.go#L24-L25

[thanm]

OK, that makes more sense now. Especially given that Delve has a top-level makefile ( as opposed to being pure "go build").
Agree that a stack trace or more info would be nice.

[fviernau]

The "OSS Review Toolkit" runs into a similar issue. The use case is utilizing go list .. [1] to determine the project dependencies / modules. The current design requires the analysis to run on a clean repository checkout, without any magic setup like running build or generate commands. However, if the embed pattern doesn't match successfully, then [1] fails with [2]. Reproduced with a minimal project like [3].

Would it make sense to provide a way to run go list with the "embed tag" ignored / disabled?

[1] go list -deps -f {{with .Module}}{{.Path}} {{.Version}}{{end}} ./...
[2] hello-world.go:9:16: pattern file.txt: no matching files found
[3]

package main
import (
    _ "embed"
    "fmt"
)

//go:generate touch file.txt
var(
    //go:embed file.txt
    file string
)

func main() {
    fmt.Println(file)
    fmt.Println("hello world")
}

[bcmills]

@fviernau, starting with Go 1.19, in theory you could use json output with a list of fields (per #29666), and if you don't request the EmbedFiles, TestEmbedFiles, or XTestEmbedFiles fields then go list shouldn't try to glob them.

I don't think we've implemented the logic to suppress those fields yet, but feel free to send a change for Go 1.20. (You can use https://go.dev/cl/392495 as a model.)

[fviernau]

Thanks @bcmills, this was very helpful!

I've finally found the time to turn it into a pull request, see #58522.

With the changes go list -deps -json=Module doesn't fail anymore if a file referred to by an embed directive doesn't exist.

[gopherbot]

Change https://go.dev/cl/540017 mentions this issue: cmd/go: print the package containing the unmatched embed patterns