Uh oh!
There was an error while loading. Please reload this page.
Rust: Strengthen isNotInstantiationOf uses - #21010
Conversation
There was a problem hiding this comment.
Pull request overview
This PR strengthens the isNotInstantiationOf predicate to prevent type explosion when resolving method calls involving integer literals with ambiguous types. The fix adds a TypePath parameter to track where concrete types differ and filters incompatibilities to only consider paths within the root type's type parameters, preventing spurious reference type candidates from being added during method resolution.
Key changes:
- Modified
isNotInstantiationOfsignature to include aTypePathparameter indicating where types differ - Added filtering logic to only consider incompatibilities within root type parameters using
path.isCons(root.getATypeParameter(), _) - Updated all call sites to pass the additional path parameter and check the path constraint
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| shared/typeinference/codeql/typeinference/internal/TypeInference.qll | Core logic change: adds TypePath parameter to isNotInstantiationOf predicate and implements wrapper that filters paths to root type parameters |
| rust/ql/lib/codeql/rust/internal/typeinference/FunctionType.qll | Updates argIsNotInstantiationOf signature to accept and forward the new TypePath parameter |
| rust/ql/lib/codeql/rust/internal/TypeInference.qll | Updates all call sites to use new signature with path filtering based on root type |
| rust/ql/test/library-tests/type-inference/main.rs | Adds test case demonstrating the literal overlap scenario with trait implementations |
| rust/ql/test/library-tests/type-inference/type-inference.expected | Updates expected test output with new type inferences for the test case |
| rust/ql/test/library-tests/type-inference/CONSISTENCY/PathResolutionConsistency.expected | Documents expected multiple targets for the new test case |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Uh oh!
There was an error while loading. Please reload this page.
Consider the following example
Inside
test, the variablexis assigned both typesi32(the default type for integer literals) andusize(because of the return type), because we do not currently support context-based typing of literals.This means that the call
x.fcan resolve to bothi32fandusizef. However, because of how we construct candidate receiver types, we also conclude that&usizeand&i32need to be considered, which means we also resolvex.ftoReff, and then because of the self-assignment, this will lead to an explosion in inferred types forx.The solution, in the case above, is to tweak how we construct candidate receiver types, by only checking non-compatibility for non-root types.
Note that this does not resolve the issue with
xhaving both typesi32andusize, and hencex.fhaving two targets.DCA is rather uneventful.