Type inference: Improve constraint matching

[hvitved]

When working on type inference for Unified, I realized that there was a (corner) case that the shared inference library did not support:

mod contextual_bound {
    #[derive(Default)]
    struct S<T>(T);

    struct MyThingB<B>(B);

    trait MyTrait<T> {}

    impl<T> MyTrait<[T; 1]> for MyThingB<T> {}

    fn bar<T1, T2: MyTrait<T1>>(x: T1, y: Option<T2>) {}

    fn test_bar() {
        let x = S(0);
        let z = MyThingB(Default::default()); // unable to infer the type of `z`
        bar([x], Some(z));
    }
}

DCA is uneventful.

[Copilot]

Copilot review overview

🟢 Approval recommended

The focused matching change has regression coverage, and the remaining corrections are documentation-only.

Review effort: Balanced
Findings: 2

Open (2)

• Align call and suffix types with the example · New
• Correct array path labels and suffix type · New

What changed in this PR

Improves shared type inference when trait constraints contain nested type parameters.

Changes:

• Adds constraint matching for nested implementation-side type paths.
• Adds Rust regression cases for direct and array-wrapped trait arguments.
• Updates generated test expectations.

File	Description
shared/​typeinference/​codeql/​typeinference/​internal/​TypeInference.qll	Extends constraint matching and documents examples.
rust/​ql/​test/​library-tests/​type-inference/​type-inference.expected	Records updated inference results.
rust/​ql/​test/​library-tests/​type-inference/​main.rs	Adds contextual trait-bound regression cases.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[paldepind]

Was this change intentional? The term here doesn't match the call to bar above? Does the existing example need changing?