Hi, could you provide more information about your use case?

Are you trying to test analyses or are you trying to create a test that runs analyses on other packages in your project?

The latter: trying to run analyzers against packages in our project via a go test. I tweaked the title to deemphasize the test part since I know it is confusing.

I'm interested in a similar use case. I'm working on a tool to run my Analyzer against packages to gather information, after which I'll want to do some final overall analysis on the collected data and output a report.

I just recently stumbled into the same problem. I wanted to run a long running service and not use any of the drivers (i.e: singlechecker) as those abstract more than I want.

I think the best way to move forward on this is to add such a library in an external package (outside of tools) and let it bake a little. I don't think there's anything (other than the obvious visibility and accessibility to potential users) that requires this to be in tools.

Once it's used more and we're happy with it we can move it back to tools.

On a related note, it would be nice if we had some sort of playground with fewer stability requirements than tools to do experiments in. As it is now once we add anything it's pretty much there forever and we can't make any changes.....

Change https://go.dev/cl/411907 mentions this issue: go/analysis/checker: a go/packages-based driver library

There is golang.org/x/tools/go/analysis/analysistest you can use this in tests, but it does not cover everything this issue requests.

Update: this issue (and some related ones) resulted in proposal #61324, which was accepted. It defines a new public API for tools that use packages.Load to load and type-check a set of packages from source and then run analyzers over them. I have a code change to implement it, but it's stale and needs a little work to bring it back up to date.

My main concern is: is it still needed? I've heard very little clamor for it since we went through the proposal process. The main downside of publishing the new API is that it may cause people to reach for it unnecessarily, and it may encourage people to write analyzers that only work in "all packages in same address space" mode, because they use stateful variables or out-of-band communication with the rest of the application. By contrast the unitchecker driver that is part of 'go vet' ensures that analyzers use the proper hygiene, and delivers incremental separate analysis, with a file-based cache, which is more scalable for large code bases.

So: do people still want this?

I think it would be great — there seem to continue to be recent comments and backlinks referencing #61324 and the related issues. IMO supporting more flexible uses of analyzers without the main/exit would encourage people to write and deploy more analyzers, which seems overall like a good outcome! (Even if they are not run from go vet)

@adonovan I was very excited when #61324 got accepted, exactly because it would enable this specific use case. Ever since then I've periodically checked whether that API has landed and was disappointed (case in point: I just checked again, which led me here). So, personally, the reason I haven't made a lot of noise about this is that I've been waiting for it to actually be available - until there's something to point at and say "look at this cool thing", I don't know how to be noisy about it.