On Sun, 20 Jul 2025 at 10:42, 'Brian Candler' via golang-nuts <
golang-nuts@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+unsubscr...@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/CAEkBMfH%2BGMVajNtZRii9wnEW75M%3Dkg%3DXQaRXtgXikxacAwyd4w%40mail.gmail.com.

Reply via email to