Rust: Make impl blocks only give rise to direct trait implementation

[paldepind]

This PR changes how we calculate the trait/implements hierarchy.

Currently an impl Trait for T block makes T directly implement both Trait and any supertraits, SuperTrait, of Trait. However, in order for this impl block to be valid, it must already be the case that T implements SuperTrait by some other impl block. Hence, the only new information from an impl block is the implementation of the specific target trait.

This PR changes how we handle impl blocks when calculating the trait/implements hierarchy, s.t. impl blocks only makes a type implement the specific trait in the impl block.

This restriction is also used in AssocFunctionType where the restriction removes some spurious call targets.

The DCA report shows a small speedup and decent reductions in "Path resolution inconsistencies" and "Nodes With Type At Length Limit". There is a small increase in "Unknown expression types". I think this increase looks reasonable when compared to the decrease in "Path resolution inconsistencies". I also did a quick and small spot check on neon, and the lost types all looked like spurious types.

[Copilot]

Pull Request Overview

This PR enhances the type inference module by adding a transitive parameter to control whether constraints should be transitively propagated through trait bounds. The key change distinguishes between impl blocks (non-transitive) and trait bounds (transitive), fixing spurious type inference results.

• Added a boolean transitive parameter to conditionSatisfiesConstraint predicate to control constraint transitivity
• Updated associated function type resolution to properly track parent traits and constraints
• Corrected documentation examples and fixed function name references in comments

Reviewed Changes

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

Show a summary per file

File	Description
shared/typeinference/codeql/typeinference/internal/TypeInference.qll	Added transitive parameter to conditionSatisfiesConstraint predicate signature and updated all call sites
rust/ql/lib/codeql/rust/internal/TypeInference.qll	Set transitive = false for impl blocks and transitive = true for trait bounds, supertraits, and related constraints
rust/ql/lib/codeql/rust/internal/typeinference/FunctionType.qll	Refactored associated function type resolution to track parent traits, updated parameter binding sets, and corrected documentation table
rust/ql/test/library-tests/type-inference/main.rs	Removed SPURIOUS markers from test expectations that are now correctly resolved
rust/ql/test/library-tests/type-inference/type-inference.expected	Removed spurious reference type inferences for loop variables
rust/ql/test/library-tests/type-inference/CONSISTENCY/PathResolutionConsistency.expected	Removed entries for calls that no longer have multiple targets
rust/ql/test/library-tests/dataflow/sources/stdin/CONSISTENCY/PathResolutionConsistency.expected	Removed spurious multiple call target entry
rust/ql/test/library-tests/dataflow/models/CONSISTENCY/PathResolutionConsistency.expected	Removed spurious multiple call target entry

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Corrected spelling of 'wether' to 'whether' and 'satisifed' to 'satisfied'.

Suggested change

	* - `transitive` corresponds to wether any further constraints satisifed
	* - `transitive` corresponds to whether any further constraints satisfied

[Copilot]

The documentation table references functions m4 and m5 that don't exist in the example code. Based on the example, line 153 should reference m1 (from the impl T1 for X block) and line 154 should reference m3 (from the impl T2 for X block).

Suggested change

	* `m4` | `impl T2 for X` | `self` | `X`
	* `m5` | `impl T2 for X` | `self` | `X`
	* `m1` | `impl T1 for X` | `self` | `X`
	* `m3` | `impl T2 for X` | `self` | `X`

[paldepind]

I'm not sure why the second test did not get fixed, especially since it looks a lot like the fourth test. I'm guessing something more might be needed here, as the AssocFunctionType looked fine when I eval'ed it.