Rust: Do not dispatch to all implementations when trait target is accurate#20969
Rust: Do not dispatch to all implementations when trait target is accurate#20969paldepind merged 4 commits intogithub:mainfrom
Conversation
paldepind
force-pushed
the
rust/dispath-default-trait
branch
from
42fd1da to
5888ed3
Compare
There was a problem hiding this comment.
Pull request overview
This PR refines Rust trait function call resolution by distinguishing between cases where trait dispatch is necessary and cases where the target can be precisely determined. The key improvement is adding a dispatch boolean parameter to track whether a resolved target is a trait item due to type ambiguity (requiring dispatch to all implementations) or a precise target (no dispatch needed).
- Modified
resolveCallTargetto return adispatchflag indicating whether the resolved target requires trait dispatch - Updated call target resolution logic to only dispatch to all trait implementations when type information is insufficient to determine a single target
- Added comprehensive test cases demonstrating correct resolution of trait default implementations vs. overridden implementations
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| rust/ql/lib/codeql/rust/internal/TypeInference.qll | Added dispatch parameter to resolveCallTarget to distinguish between precise targets and trait items requiring dispatch |
| rust/ql/lib/codeql/rust/elements/internal/CallImpl.qll | Updated getARuntimeTarget to only dispatch to implementations when dispatch=true, ensuring precise targets don't trigger unnecessary dispatch |
| rust/ql/lib/codeql/rust/elements/internal/InvocationExprImpl.qll | Updated getResolvedTarget to accommodate new resolveCallTarget signature |
| rust/ql/test/library-tests/dataflow/global/main.rs | Added test module demonstrating trait default implementations vs. overridden implementations with proper call resolution |
| rust/ql/test/library-tests/dataflow/global/viableCallable.expected | Updated expected test results showing correct resolution of trait calls without unnecessary dispatch |
| rust/ql/test/library-tests/dataflow/global/inline-flow.expected | Updated expected dataflow results for new test cases |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
geoffw0
left a comment
geoffw0
left a comment
There was a problem hiding this comment.
Tests, DCA, QL all LGTM.
| | | ||
| result = call.(MethodResolution::MethodCall).resolveCallTarget(i, _, _) or | ||
| result = call.(NonMethodResolution::NonMethodCall).resolveCallTargetViaTypeInference(i) | ||
| ) |
There was a problem hiding this comment.
For method calls, is it always resolved by type inference?
There was a problem hiding this comment.
Well, "method call" is a bit of an overloaded term now 😅
Syntactic method calls from MethodCallExpr are always resolved by type inference.
Semantic methods calls (any expression that ends up calling a method, such as Trait::method(ting)) are mostly resolved by type inference. I don't have all of the details in my mind right now. But, for instance the simple case like Vec::new is resolved by path resolution.
3 participants
Currently when a call resolves to a trait function we enable dispatching to all implementations of that trait function. However, sometimes when a trait function has a default implementation, it is actually the one and only correct result. See the tests for an example.
This PR restrict the dispatching to the cases where the trait function is the resolved target because type information is not enough to find a single correct target.