Russ Cox

Agreed. v0.12.0 does this for the output of things like Ldef and Lrefs, but a few more cases remain to be fixed.

Fixed with roughly the same diff in v0.12.0. Note that acme-lsp has moved: `go install 9fans.net/acme-lsp/cmd/acme-lsp@latest` for the fix.

This doesn't look right to me. TestFiles has a well-understood meaning already: \*\_test.go files. If a build system has the concept of a package that can only be imported by...

This proposal has been added to the [active column](https://go.dev/s/proposal-status#active) of the proposals project and will now be reviewed at the weekly proposal review meetings. — rsc for the proposal review...

I disagree. Putting them in TestFiles makes it sound like they are _test.go files, and they aren't. I think you are overfitting to this one specific use case. Better to...

Based on @lfolger's recent message, it sounds like https://github.com/golang/go/issues/65749#issuecomment-1973571611 works for everyone. This would mean adding a TestOnly bool to x/tools/go/packages, but the cmd/go integration would never emit it. Only...

It stops being an API if arbitrary data can be passed between Blaze and analyzers. Let's add what we need and document what it means. TestOnly seems like a reasonable...

Have all remaining concerns about this proposal been addressed? The proposal is to add ``` TestOnly bool // package is marked as "test-only" in the build system (not possible using...

Based on the discussion above, this proposal seems like a **[likely accept](https://go.dev/s/proposal-status#likely-accept)**. — rsc for the proposal review group The proposal is to add ``` TestOnly bool // package is...

Does vet differ from the compiler here? Presumably the go command passes the same version to both. If it does differ, why does it differ?