Rust: Type inference for impl trait types with type parameters#20119
Merged
paldepind merged 6 commits intogithub:mainfrom Jul 28, 2025
Merged
Rust: Type inference for impl trait types with type parameters#20119paldepind merged 6 commits intogithub:mainfrom
paldepind merged 6 commits intogithub:mainfrom
Conversation
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR implements type inference for impl trait types that contain type parameters from their enclosing function. The implementation allows proper handling of return position impl types that reference function type parameters, such as fn get<T: Clone>(x: T) -> impl MyTrait<T>.
Key changes:
- Adds support for type parameters within
impltrait types by creatingImplTraitTypeParameterobjects - Updates type inference logic to properly handle and rank these new type parameters
- Extends test coverage with various scenarios of parameterized
impltrait return types
Reviewed Changes
Copilot reviewed 8 out of 9 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| main.rs | Adds comprehensive test cases for impl trait types with type parameters |
| PathResolutionConsistency.expected | Updates line number references due to test additions |
| TypeMention.qll | Implements type resolution for ImplTraitTypeParameter |
| TypeInference.qll | Extends type parameter ranking system to handle ImplTraitTypeParameter |
| Type.qll | Core implementation of ImplTraitTypeParameter class and related logic |
| ImplTraitTypeReprImpl.qll | Adds getFunctionReturnPos() method to locate containing function |
| .gitattributes & .generated.list | Removes generated file markers for ImplTraitTypeReprImpl.qll |
geoffw0
reviewed
Jul 25, 2025
Contributor
geoffw0
left a comment
There was a problem hiding this comment.
Mostly questions to aid my own understanding...
rust/ql/lib/codeql/rust/elements/internal/ImplTraitTypeReprImpl.qll
Outdated
Show resolved
Hide resolved
geoffw0
approved these changes
Jul 28, 2025
Contributor
geoffw0
left a comment
There was a problem hiding this comment.
All concerns addressed. 👍
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.
We currently can't handle
impltypes with type parameters inside them, such as this example whereToccurs within theimpl:The example is from the draft PR: #19954
This PR fixes the problem by letting type parameters of the function where the return position
imploccurs also induce a type parameter of theimpltype.In the above example
gethas a type parameterTwhich occurs in theimplin return position. Hence a type parameter corresponding toTis added to theimpltype. Whengetis called an a specific type is known forTthen that type will be instantiated inside the returnedimpltype.This implementation is a bit different from the draft one in #19954. That implementation relies on inferring trait types directly. I.e. elements of
impl Foo + Barwill have both the typeFooandBar. That is a perfectly fine implementation, but I believe this approach has two advantages:impltype.