Go: fix database inconsistency when receiver has alias type #19464
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`types.Unalias` already does the same thing
There was a problem hiding this comment.
Pull Request Overview
This PR ensures that alias types are unaliased before looking up or labeling methods and types, fixing a database inconsistency when a method receiver uses an alias.
- Unalias receiver types in
findMethodWithGivenReceiverso methods on alias types resolve correctly. - Remove
resolveTypeAliashelper and replace its uses withtypes.UnaliasinextractTypeandgetTypeLabel.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| go/extractor/trap/labels.go | Unalias the receiver’s type before searching for matching methods. |
| go/extractor/extractor.go | Inline alias resolution by replacing resolveTypeAlias with types.Unalias in type extraction and labeling. |
Comments suppressed due to low confidence (3)
go/extractor/trap/labels.go:172
- Add a unit test for
findMethodWithGivenReceiverthat defines a method on an alias receiver (e.g.,Impl6Alias) and verifies the method is found correctly to prevent future regressions.
unaliasedType := types.Unalias(object.Type())
go/extractor/extractor.go:1588
- Add tests for
extractTypeto confirm alias types are unaliased before labeling, ensuring no alias-related inconsistencies in the database.
tp = types.Unalias(tp)
go/extractor/extractor.go:1766
- Add tests for
getTypeLabelto verify that types supplied viatypes.Unaliasproduce consistent labels for both aliased and unaliased inputs.
tp = types.Unalias(tp)
mbg
reviewed
May 6, 2025
mbg
approved these changes
May 6, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It was reported that
codeql/go/ql/test/library-tests/semmle/go/aliases/InterfaceImplsfailsDB-CHECKif you add--check-databasesto the test target ofcodeql/go/Makefile. This turns out to be because that test has a method defined on a receiver which is an aliasImpl6Aliasof the typeImpl6. This is equivalent to defining the method onImpl6directly. There is some code in the extractor which makes sure that objects which are receiver variables get a special label which is the same when seen from different files. That code was not unaliasing the type of the receiver. This PR fixes that, which fixes the db inconsistency.I do not think this needs any tests. I also don't think it needs a change note.
I also included a minor drive-by refactor. We were defining our own wrapper around
types.Unaliaswhen we don't need to (because it already has the property we want, i.e. being idempotent for non-alias types).