/cc @jayconrod @jadekler

Jay is for sure the expert here, but

add a phase to my current run of []*analysis.Analyzer and reuse the parsing that is already done

Could you enlighten me as to what this means? You have some existing tool - perhaps gopls - that is doing AST parsing, and you want to feed that AST to gorelease rather than it re-parsing?

What is the benefit - some performance gains? If so, how much do you anticipate gaining? Is this a nice-to-have, or blocking your workflow?

(I'm pretty ignorant to the broader tooling infrastructure, and trying to learn, so that's where the questions are aimed :) )

Could you enlighten me as to what this means? You have some existing tool - perhaps gopls - that is doing AST parsing, and you want to feed that AST to gorelease rather than it re-parsing?

Sure, so I use golangci-lint, a metalinter, that uses the analysis.Analyzer interface to plug together all the govet checks and a bunch of third party ones from the community. It would be trivial to add a new gorelease linter to that project.

What is the benefit - some performance gains? If so, how much do you anticipate gaining? Is this a nice-to-have, or blocking your workflow?

In one of the worst examples, 200k loc, it takes 49s. While golangci-lint can take order of minutes, I imagine most of that delay for gorelease is file reading and AST parsing. Plus golangci-lint has a nice diff feature to just lint lines that changes, which is nice for local checks before pushing to ci.

That being said, we have a workflow today and with #37561, we could technically automate the reporting much like golangci-lint does today.

I like the idea of having an analyzer that protects against incompatible changes.

Architecturally, I guess this fits in somewhere between gorelease and apidiff. There isn't a layer there now, so this would be a pretty big change. I wonder if it should just be a separate tool from gorelease?

The weird bit here I suppose is that the analyzer needs a base version to compare against, which might require downloading a module into the cache. It's fine for gorelease to do that, but it seems unusual for an analyzer.

Yeah, putting this in a new package or apidiff would be fine by me.

Also you are not wrong, but it does feel like an Analysis.Fact or analysis.Analyser.ResultType, and I think I can make a solid case for it. And I have gotten traction on some weirder asks form the analysis team, #44753.

This would be a fair significant change. analysis.Analyzers work on a single package at a time. These can communicate using Fact edges from imported packages (within the same Analyzer) and Results between Analyzers on the same package. {single,multi}checker.Main() take a list of packages and a list of analyzers and output a a list of Diagnostics (+ some extra output). Packages are loaded using packages.Load().

I am looking into making analysis support running list of root packages.Packages and a list of analysis.Analyzers and returning the Facts and Diagnostics of the root actions. (Exposing Results runs into trouble with unitchecker's requirements.) Calling this would likely happen outside of a {single,multi}checker.Main(). I suspect this is not quite compatible with your all of your goals.

The main problem with trying to do this in the analysis package is that it is missing information. You need to load pkg@123 and pkg@234, and encode that there is a relationship between pkg@123 and pkg@234. You will need to make this available to a single Pass, i.e. (Analyzer, Package) pair, that can see all of this information at once. How do you plan on making all of this information available to a Pass?

It would be a bit of duplication of effort, but I think that, for a given pkg@234: the current code in a repo, a single analysis.Analyzer could calculate and parse the information for the same package, from the current release of a given module, pkg@123 in your example, then then analysis.Analyzers looking to compare to the "latest release" can depend on that package and do a diff, gorelease being one of them. (I am assuming that some teams may want to introduce different compatibility guarantees, since I have already seen evidence of this, and want to make my abstract design scalable.)

It would be nice to have a module level, I think "root packages.Packages" in your parlance, task that can calculate "latest release" then each package can generate off this, but "fetch latest release" is pretty cheap, and you can still do the ast parsing at the package level for the old version.

@timothy-king: Let me know if this is unclear or you would like more detail.