Skip to content

Switch to analytics.Pass for type metadata - #72

Merged
alexkohler merged 1 commit into
alexkohler:masterfrom
NathanBaulch:analyticspass
Feb 17, 2026
Merged

Switch to analytics.Pass for type metadata#72
alexkohler merged 1 commit into
alexkohler:masterfrom
NathanBaulch:analyticspass

Conversation

@NathanBaulch

Copy link
Copy Markdown
Contributor

Significant type resolution improvement by switching to the standard analysis.Pass metadata. Previously this type information was only available for custom types defined within the file being analyzed. This PR also allows us to remove the naive type inference code in types.go.

@alexkohler alexkohler left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL about analytics.Pass - thanks!

@alexkohler
alexkohler merged commit 7d3438d into alexkohler:master Feb 17, 2026
1 check passed
@NathanBaulch
NathanBaulch deleted the analyticspass branch February 17, 2026 19:20
@NathanBaulch

Copy link
Copy Markdown
Contributor Author

I should probably mention @alexkohler that this represents a breaking API change that will require upstream changes in golangci-lint. I don't fully understand how the determination is made but I believe deep type analysis puts us in the "slow" category of linters. IMO this is fine since prealloc is off by default (and generally not recommended), so it's something users already opt into.
Just thought you should take this into consideration when you tag the next release.

@alexkohler

Copy link
Copy Markdown
Owner

I should probably mention @alexkohler that this represents a breaking API change that will require upstream changes in golangci-lint. I don't fully understand how the determination is made but I believe deep type analysis puts us in the "slow" category of linters. IMO this is fine since prealloc is off by default (and generally not recommended), so it's something users already opt into. Just thought you should take this into consideration when you tag the next release.

Thank for flagging this. AIUI, the workaround here would be to have golang-ci-lint to use v1.0.3 (per our other thread), is that right?

@NathanBaulch

NathanBaulch commented Feb 24, 2026

Copy link
Copy Markdown
Contributor Author

In the short term, yes. Dependabot should detect this new v1.0.3 tag and pull it into golangci-lint upstream shortly. For the next release I recommend incrementing to v1.1.0 to signal an API change that will need human intervention (likely myself) in golangci-lint.

@alexkohler

Copy link
Copy Markdown
Owner

Got it, thanks. I tagged/pushed v1.1.0 at 2108c81 (current HEAD of master).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants