Thanks for the links, Sean. I was unaware of these issues and they seem to be working towards a very similar goal - I'll drop a note somewhere appropriate that links in Axel's typed struct tags issue.
Re: source text, it seems like embedding at some point in routines under src/cmd/go/internal/test/test.go and src/cmd/go/internal/load/test.go would work out. It seems like the ideas in issues Sean mentioned or my fingerpainting are last-mile stuff, because the changes are small, but they also would happen in a fair number of disparate places. On Sunday, July 20, 2025 at 4:12:48 AM UTC-7 Axel Wagner wrote: > On Sun, 20 Jul 2025 at 10:42, 'Brian Candler' via golang-nuts < > golan...@googlegroups.com> wrote: > >> Does the compiled binary even carry enough information about the original >> source to be able to do that, for a useful set of analyses? >> > > It could: > > //go:embed *.go > var source embed.FS > > `go test` can choose to embed whatever it wants into the binary. > > >> I think that's why people are using `os/exec` to run linters - they >> generally work on source code, not object code. >> >> On Sunday, 20 July 2025 at 00:03:21 UTC+1 Andrew Harris wrote: >> >>> x/tools/go/analysis <https://pkg.go.dev/golang.org/x/tools/go/analysis> >>> states "[a]n analysis reports mistakes is informally called a 'checker'". >>> While checkers are extensional - and Go is tangibly not sine qua non about >>> extensions - the foundations are there and they seem appropriate in the >>> right circumstances. Analyses employed by `go vet` or `gopls` demonstrate >>> the utility of checkers within the standard Go distribution. >>> >>> It seems like, while there are enough options out there, there's no >>> really immediate way to run a checker from a third party from the standard >>> distribution. One reasonable question is whether this really is a gap in >>> the ecosystem, or if it's fine to leave alone. Static analyzers don't have >>> to be checkers, and the ones that aren't that sharp don't make sense here. >>> Another question, though: for well-formulated checkers, could `go test` be >>> a platform for running them? I'm wondering if it'd be plausible to run a >>> checker very much like a test function. Or if I'm missing something that >>> makes the notion obviously implausible. As a very crude illustration: >>> >>> ``` >>> -- local_test.go -- >>> package local >>> >>> import ( >>> "testing" >>> >>> "github.com/some/checker" >>> ) >>> >>> func TestChecker() { >>> testing.Analyze(checker.Check() >>> } >>> ``` >>> >>> The details would be a bit magic, with a fair amount of implicit >>> behavior: >>> - There'd be no *testing.T argument (not sure about this, but just for >>> illustration...) >>> - `checker.Check()` would not be an `analysis.Analyzer`, but eventually >>> serves to partially initialize one with analysis logic. Roughly, I think >>> the type of `checker.Check()` could be some interface. Indirection and >>> assertions behind the scenes could be employed such that `analysis` isn't >>> an explicit dependency in `local` or `testing`; `analysis` would likely be >>> a dependency in `checker`. >>> - the `analysis.Analyzer` is employed by an `analysis.Pass` populated by >>> `testing` - the set of files it examines are naturally described by the >>> invocation of `testing` >>> - `testing` would arrange for this `analysis.Pass` to run once before >>> other tests, aggregating all `testing.Analyze` inputs to run with that pass >>> - problems detected by checkers would manifest like other fatal >>> `testing` outcomes: halting, failing, and logging a relevant message >>> - a really very, very magic thing would be for `gopls` to detect >>> `testing.Analyze` calls ... >>> >>> The closest prior art here I've found is >>> https://github.com/surullabs/lint, it has a stated purpose of having >>> "lint checks to be part of a regular go build + go test workflow". But it's >>> also using `os/exec` to run linters - that seems like a red flag. It also >>> doesn't stress checkers versus linting for style, etc. Also in terms of >>> prior art, I don't think it's entirely unnatural to end up with something >>> ad-hoc along the same lines when developing around code generation or >>> reflection. >>> >>> I should note I'm definitely seeing this because of discussion around >>> struct tags on https://github.com/golang/go/issues/73787, >>> https://github.com/golang/go/issues/74472#issuecomment-3061802569. >>> https://github.com/golang/go/issues/74376 seems like an example of >>> using static analysis over json tags in a way that would be possible to `go >>> test`. It's not necessary with `go vet` and `gopls` coverage, but I think >>> that putting equivalent pieces together isn't really convenient for third >>> party solutions ... maybe it could be? >> >> -- >> > You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> > To view this discussion visit >> https://groups.google.com/d/msgid/golang-nuts/fbd9c6bf-62e4-4ecd-9fdd-b35d49c1d1d5n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/fbd9c6bf-62e4-4ecd-9fdd-b35d49c1d1d5n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/d1afdfb8-8d45-4027-93d7-a0fc7be864dan%40googlegroups.com.