Rust: Improve handling of where clauses in type inference and path resolution

[paldepind]

It turns out that we don't handle type bounds added by where clauses in all cases in path resolution and type inference.

This PR improves the situration by adding member predicates to traits and type parameters that take all sources of bounds into account. These are then used in path resolution and type inference.

[geoffw0]

Looks promising, I think I've spotted a couple of bugs (I could be wrong), and we need to review DCA when it's finished.

[geoffw0]

It appears to be legal to have two where predicates with Self as the path, e.g.:

    trait Subtrait
    where
        Self: Supertrait1,
        Self: Supertrait2,

I think at the moment this will break your index numbering.

[paldepind]

You're right, that is legal and the implementation currently does not account for that.

[Copilot]

Pull Request Overview

This PR improves handling of where clauses in Rust type inference and path resolution by ensuring type bounds from where clauses are properly considered alongside direct trait bounds. The changes add member predicates to traits and type parameters that aggregate bounds from all sources (direct bounds and where clauses) and update path resolution and type inference to use these comprehensive bound collections.

Key Changes:

• Added getATypeBound() and getTypeBound(int) methods to traits and type parameters that include both direct bounds and where clause bounds
• Updated type inference and path resolution logic to use the new comprehensive bound predicates
• Added test cases covering where clause scenarios for trait bounds and supertrait relationships

Reviewed Changes

Copilot reviewed 9 out of 10 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
rust/ql/lib/codeql/rust/elements/internal/TypeParamImpl.qll	Adds methods to collect type bounds from both direct bounds and where clauses for type parameters
rust/ql/lib/codeql/rust/elements/internal/TraitImpl.qll	Adds methods to collect type bounds from both direct bounds and where clauses for traits
rust/ql/lib/codeql/rust/internal/TypeInference.qll	Updates type inference to use new comprehensive bound collection methods
rust/ql/lib/codeql/rust/internal/PathResolution.qll	Updates path resolution to use new comprehensive bound collection methods and simplifies bound checking logic
rust/ql/test/library-tests/type-inference/main.rs	Adds test cases for where clause scenarios in type inference
rust/ql/test/library-tests/path-resolution/main.rs	Adds test cases for where clause scenarios in path resolution

[Copilot]

[nitpick] The getTypeBoundAt method uses magic numbers and has unclear indexing logic. Consider adding documentation to explain the indexing scheme where i=0 represents direct bounds and i>0 represents where clause predicates, or use more descriptive parameter names like source and boundIndex.

[Copilot]

[nitpick] The hardcoded string comparison getText() = \"Self\" is fragile and may not handle all valid representations of Self. Consider using a more robust method to identify Self type references, such as checking the resolved type or using semantic analysis rather than text comparison.

Suggested change

	wp.getTypeRepr().(PathTypeRepr).getPath().getText() = "Self" and
	wp.getTypeRepr() instanceof SelfTypeRepr and

[geoffw0]

I feel like this case should simplify to tbl = this.(TypeParamItemNode).getWherePred(i).getTypeBoundList() (except that getWherePred(i) doesn't exist there). I don't feel strongly if this is a pain to change.

[paldepind]

I'll give it a try. I had that predicate before, but ran into non-monotonic recursion. But it should be doable as long as the getWherePred(i) is not actually used in path resolution itself.

[paldepind]

I agree that what you propose is a lot cleaner, but the getWherePred on TypeParamItemNode would have to use rank and then we got non-monotonic recursion 😢

[paldepind]

The performance regression in this PR should be fixed by #20155. I think it's ok to merge this PR first, as I need the new getTypeBoundAt predicate over in #20133.