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.

Reply via email to