Type inference: Unify getABaseTypeMention and conditionSatisfiesConstraint#21850
Open
hvitved wants to merge 1 commit into
Open
Type inference: Unify getABaseTypeMention and conditionSatisfiesConstraint#21850hvitved wants to merge 1 commit into
getABaseTypeMention and conditionSatisfiesConstraint#21850hvitved wants to merge 1 commit into
Conversation
0940579 to
3f7b50e
Compare
Contributor
Author
Rerun has been triggered: 4 restarted 🚀 |
Contributor
Author
Rerun has been triggered: 2 restarted 🚀 |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR unifies type-hierarchy handling in the shared type inference library by removing getABaseTypeMention and relying on conditionSatisfiesConstraint for matching argument types against parameter types involving type parameters (covering both class hierarchies and Rust trait-style constraints).
Changes:
- Removed
getABaseTypeMentionfrom the sharedInputSig2interface and deleted the associated base-type-mention traversal logic. - Reworked base-type matching to use the
conditionSatisfiesConstrainthierarchy when inferring type arguments for accesses. - Updated Rust’s type inference instantiations of
InputSig2to match the new interface (removing now-defunct stubs).
Show a summary per file
| File | Description |
|---|---|
| shared/typeinference/codeql/typeinference/internal/TypeInference.qll | Removes the base-type-mention API and routes base-type inference through conditionSatisfiesConstraint; updates related documentation/comments. |
| rust/ql/lib/codeql/rust/internal/typeinference/TypeInference.qll | Drops getABaseTypeMention stub implementations to conform to the updated shared signature. |
Copilot's findings
Comments suppressed due to low confidence (1)
shared/typeinference/codeql/typeinference/internal/TypeInference.qll:397
- In the Rust examples explanation, the sentence says “
conditionandconditionare identical”; the second identifier should beconstraint. Also “seconds example” should be “second example”.
* the meaning is "`T` implements `Trait`" where the constraint is only
* valid for the specific `T`. Note that `condition` and `condition` are
* identical in the two examples. To encode the difference, `abs` in the
* first example should contain `T` whereas in the seconds example `abs`
* should be empty.
- Files reviewed: 2/2 changed files
- Comments generated: 1
| @@ -1839,7 +1715,7 @@ module Make1<LocationSig Location, InputSig1<Location> Input1> { | |||
| directTypeMatch(a, e, target, path, t, tp) | |||
| or | |||
| // We can infer the type of `tp` by going up the type hiearchy | |||
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
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.
This PR removes
getABaseTypeMention, and instead ensures that sub-type relations expressed in terms ofconditionSatisfiesConstraintare taken into account when matching types of arguments against types of parameters containing type parameters:getABaseTypeMentionwas not in use in Rust, so this PR has no semantic effect on Rust, but for languages with type hierarchies, such as Swift, it means that we can treat type hierarchies in the same way that traits are treated in Rust.#21837 has been used to verify this PR.