Rust: Restrict type propagation into arguments

[hvitved]

Type propagation into arguments is needed in cases like

let x = Vec::new();
x.push(0); // the type `i32` must propagate into `x` to infer that `x` has type `Vec<i32>`

Up until now, we have unconditionally propagated types into all arguments, which can sometimes lead to explosions in inferred types.

This PR circumvents such explosions by only propagating type information into arguments when those arguments are potentially context-typed (such as Vec::new and Default::default).

DCA looks great: we almost get the Nodes With Type At Length Limit count down to 0, sacrificing only a relatively small amount of resolvable calls.

[Copilot]

Pull Request Overview

This PR introduces context-based typing for Rust function calls to improve type inference accuracy and reduce combinatorial explosions. The changes implement a mechanism to track when function return types depend on context (like Default::default() or Vec::new()) rather than their arguments.

Key Changes

• Introduced a new TContextType type to mark context-typed expressions
• Added ContextTyping module to identify and handle context-typed calls
• Modified type inference to prevent type information from flowing into arguments unless they are context-typed
• Updated test expectations to reflect improved type inference results

Reviewed Changes

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

Show a summary per file

File	Description
rust/ql/lib/codeql/rust/internal/Type.qll	Added new TContextType and ContextType class for context-based typing
rust/ql/lib/codeql/rust/internal/TypeInference.qll	Implemented ContextTyping module and integrated context checking into method and non-method call type inference
rust/ql/lib/codeql/rust/internal/typeinference/FunctionType.qll	Filtered out TContextType in argument substitution
rust/ql/lib/codeql/rust/internal/typeinference/BlanketImplementation.qll	Filtered out TContextType in blanket implementation type resolution
rust/ql/test/library-tests/type-inference/type-inference.ql	Added import and filter to exclude TContextType from test output
rust/ql/test/library-tests/type-inference/main.rs	Added test cases for context-typed calls with trait implementations
Various *.expected files	Updated expected test results reflecting improved type inference

---

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

[paldepind]

I need to better understand how this relates to the existing certain type machinery and what we want to do going forward.

There clearly is some overlap between the two things. With certain types we can find places where we need to do speculative inference with:

not exists(infersCertainTypeAt(n, path)) }

And with context types we can find places where we need to do speculative inference with:

inferType(n, path) = TContextType()

In the former case we're marking places with certainty and in the latter we're marking places with uncertainty. In the former case, too few marking leads to too many types (over approximation) and in the latter case too few markings leads to too few types (under approximation).

It seems that certain type inference can block spurious types in ways that context types cannot:

struct MyA {}
struct MyB {}

impl Default for MyA { fn default() -> Self { MyA {} } }

impl Deref for MyA {
    type Target = MyB;
    fn deref(&self) -> &Self::Target { &MyB {} }
}

fn take_a(_b: &MyA) {}
fn take_b(_b: &MyB) {}

fn test() {
    let x: MyA = Default::default(); // Certain types prevent `x : MyB`
    take_a(&x);
    take_b(&x);

    let y = Default::default(); // Context types can not prevent `x : MyB`
    take_a(&y);
    take_b(&y);
}

So maybe we could instead expand on the existing certain type inference? Or are there things that context type can prevent that certain types cannot? Having an example of such a thing as a test would be great.

We should also infer context types for:

• Integer literals — the type of i could depend on the call in let i = 0; f(i).
• Constructor calls/struct expressions with generics — the generic in m could depend on the call in let n = None; f(n).

[hvitved]

Or are there things that context type can prevent that certain types cannot? Having an example of such a thing as a test would be great.

Anything involving method calls will be difficult to support, since we cannot monotonically determine when a method call has a unique target and hence has a unique return type.

[hvitved]

We should also infer context types for:

• Integer literals — the type of i could depend on the call in let i = 0; f(i).

Right now i would be getting two types (if the type of f's argument is not i32), are you suggesting we keep it that way?

• Constructor calls/struct expressions with generics — the generic in m could depend on the call in let n = None; f(n).

Yes, your are right, I forgot about those.