Rust: Non-symmetric type propagation for lub coercions

[hvitved]

Rust applies least-upper bound coercions for certain constructs, such as the branches of an if expression, which means that is not sound to propagate type information directly between branches. In fact, doing so can lead to type inference explosions, as witnessed by the example added on this PR.

Instead of attempting to model lub coercions, we simply prevent type information to propagate from one branch to another by going directly via the type of the if expression (and similar for other constructs with lub coercions).

DCA looks great; we recover the performance lost on #20282 for ruff, rendiation, and coreutils.

[Copilot]

Pull Request Overview

This PR addresses a type inference performance issue in Rust by preventing symmetric type propagation for constructs that use least-upper bound (LUB) coercions, such as if expressions and match arms with multiple branches.

Key Changes:

• Introduced non-symmetric type propagation for LUB coercion contexts to prevent type inference explosions
• Restricted symmetric type equality to single-branch/single-element cases
• Added a test case demonstrating the type inference explosion scenario

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
rust/ql/lib/codeql/rust/internal/TypeInference.qll	Implements non-symmetric type propagation via new predicates lubCoercion and typeEqualityNonSymmetric, and restricts symmetric propagation for multi-branch constructs
rust/ql/test/library-tests/type-inference/main.rs	Adds test case with if expression demonstrating type inference explosion scenario
rust/ql/test/library-tests/type-inference/type-inference.expected	Updates expected test output reflecting reduced type inference results due to non-symmetric propagation

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The predicate checks lubCoercion(mid, n2, suffix) but doesn't verify that n1 is also a child of mid that would be subject to LUB coercion. This could lead to unintended type propagation paths. Consider adding a check to ensure n1 is also a relevant child of mid when n2 is subject to LUB coercion.

[geoffw0]

I had the same concern, it looks like n1 is bound by type but not by location in the program.

What would the Rust code this logic targets look like?

[hvitved]

For example, if we have

let x = if b {A}else{C}

then

1. Type information flows from A and B to the entire if.
2. Type information does not flow from if to neither A nor B.
3. Type information flows in both directions between if and x.
4. If type information can flow from something to x, then it also flows to A, but only when that something is not B (and vice versa).

Does that make sense?

[geoffw0]

Ah, I was reading typeEquality as "these types are equal" (potentially by coincidence, e.g. two unrelated u32s in the program) whereas it is in fact "these types must be equal" (by type inference). So n1 is in fact quite tightly bound by typeEquality. And I should've read the qldoc for typeEquality.

[geoffw0]

DCA is indeed excellent.

Couple of questions and comments.

[geoffw0]

I had the same concern, it looks like n1 is bound by type but not by location in the program.

What would the Rust code this logic targets look like?