Type inference: Improve base type matching

[hvitved]

Before this PR, type information could only propagate backwards through sub typing when using type constraints (because that is the only form supported in Rust):

class Base<B> {
  init(_ b : B) { }
}

class Derived<D> : Base<[D]> {  }

func foo<T1, T2: Base<T1>>(_ value1: T1, _ base: T2) {  }

func bar<T1>(_ value1: T1, _ base: Base<T1>) { }

foo([0], Derived([])) // works: can infer the element type of `[]` to be `Int`
bar([0], Derived([])) // doesn't work: cannot infer the element type of `[]` to be `Int`

This PR closes that gap, which is needed for proper handling of inherited constructors in Swift.

DCA is uneventful for both Rust and Swift.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Shared type-inference semantics affect multiple frontends and warrant human validation despite focused Swift coverage.

Review effort: Balanced
Findings: 1

Open (1)

• Use the declared Derived type in the example invocation · New

What changed in this PR

Improves nested generic type inference through base-type relationships.

Changes:

• Matches type parameters across nested base-type paths.
• Supports contextual inference for empty array literals.
• Adds Swift generic-inheritance tests and updated expectations.

File	Description
unified/​ql/​test/​library-tests/​type-inference/​type-inference.expected	Updates generated inference results.
unified/​ql/​test/​library-tests/​type-inference/​generics.swift	Adds nested generic inference cases.
unified/​ql/​lib/​codeql/​unified/​internal/​typeinference/​TypeInference.qll	Models unknown empty-array element types.
unified/​ql/​lib/​codeql/​unified/​internal/​FacadeAst.qll	Exposes array element counts.
shared/​typeinference/​codeql/​typeinference/​internal/​TypeInference.qll	Adds nested base-type parameter matching.

---

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

[paldepind]

Two questions:

• Shouldn't we take variance into account? For instance, this type propagation does not make sense for contravariant positions such as the return position? Might it makes sense to have variance encoded on access positions with a type that can be invariant/contravariant/covariant?

• I wonder if it wouldn't be possible to reuse more of the existing contraint propagation? I haven't thought this through in terms of the QL, but intuitively foo and bar in your example are very similar. Would it not be possible to ensure that they're covered by the same code path and that constraints on parameters are picked up both through type parameters and through direct types that can be subtyped?

[hvitved]

• Shouldn't we take variance into account? For instance, this type propagation does not make sense for contravariant positions such as the return position? Might it makes sense to have variance encoded on access positions with a type that can be invariant/contravariant/covariant?

Ideally, yes, but that is already not supported, but we might consider it for the future.

• I wonder if it wouldn't be possible to reuse more of the existing contraint propagation? I haven't thought this through in terms of the QL, but intuitively foo and bar in your example are very similar. Would it not be possible to ensure that they're covered by the same code path and that constraints on parameters are picked up both through type parameters and through direct types that can be subtyped?

I thought about doing that, but I went for the simpler solution for now.

[paldepind]

Thanks for the answers. I think we should look into that in the future, but this also LGTM as-is! :)