Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Comments

Rust: Restrict type propagation into receivers#21333

Open
hvitved wants to merge 3 commits intogithub:mainfrom
hvitved:rust/type-inference-restrict-receiver-type-propagation
Open

Rust: Restrict type propagation into receivers#21333
hvitved wants to merge 3 commits intogithub:mainfrom
hvitved:rust/type-inference-restrict-receiver-type-propagation

Conversation

@hvitved
Copy link
Contributor

@hvitvedhvitved commentedFeb 17, 2026
edited
Loading

Fixes a source of type inference combinatorial explosion (see test), which fixes a timeout onstalwartlabs/stalwart.

DCA is great: only a modest decrease inPercentage of calls with call target, but on the other hand a large decrease inNodes With Type At Length Limit.

@github-actionsgithub-actionsbot added the RustPull requests that update Rust code labelFeb 17, 2026
@hvitvedhvitvedforce-pushed therust/type-inference-restrict-receiver-type-propagation branch from652c8db toe587541CompareFebruary 17, 2026 12:44
@hvitvedhvitved added the no-change-note-requiredThis PR does not need a change note labelFeb 17, 2026
strictcount(Expr e | bodyReturns(parent, e)) > 1 and
prefix.isEmpty()
or
exists(Struct s |
Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This change is not what solves the timeout, but I saw cases where type information would incorrectly flow between limits in range expressions, so I decided to treat them as LUB conversions.

@hvitvedhvitved marked this pull request as ready for reviewFebruary 17, 2026 19:29
@hvitvedhvitved requested a review froma team as acode ownerFebruary 17, 2026 19:29
Copy link
Contributor

CopilotAI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Pull request overview

This PR restricts type propagation into method receivers to fix a combinatorial explosion issue in Rust type inference, addressing a timeout on thestalwartlabs/stalwart repository. The change prevents type information from being propagated back into receiver positions during type inference, since the receiver type must already be known for method resolution to occur.

Changes:

  • Modified type inference logic to restrict type propagation into receivers by introducing a new predicateassocFunctionMentionsTypeParameterAtNonRetPos and updating the context typing logic to never propagate types directly into receivers when the prefix is empty
  • Refactored the type inference signature fromboolean isReturn toFunctionPosition pos for more precise position tracking
  • Moved Range type parameter constraints fromtypeEquality tolubCoercion to better reflect their coercion semantics
  • Added a regression test demonstrating the combinatorial explosion scenario with recursive enum types and method chaining

Reviewed changes

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

FileDescription
rust/ql/lib/codeql/rust/internal/typeinference/TypeInference.qllCore type inference logic changes: refactored position tracking, added receiver restriction, moved Range coercion logic, and simplified several helper predicates
rust/ql/test/library-tests/type-inference/regressions.rsNew regression test file demonstrating the combinatorial explosion case with recursive enum types
rust/ql/test/library-tests/type-inference/main.rsAdded module declaration for the new regressions test file
rust/ql/test/library-tests/type-inference/type-inference.expectedUpdated expected output reflecting the restricted type propagation (one line removed at 9514, new entries added for regression test)

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
pos.isPosition()
or
// Never propagate type information directly into the receiver, since its type
// must already have been known in order to resolve the call
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Is this always true? Can we not have cases where a non-self argument is used to find the receiver?

// Never propagate type information directly into the receiver, since its type
// must already have been known in order to resolve the call
pos.isSelf() and
not prefix.isEmpty()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

We already know thatpos is not a return position, so we can simplify this a bit.

Suggested change
notprefix.isEmpty()
// Never propagate type information directly into the root of the receiver, since its type
// must already have been known in order to resolve the call
pos.isSelf()impliesnotprefix.isEmpty()

}

private module ForIterableSatisfiesConstraint =
SatisfiesConstraint<ForIterableExpr, ForIterableSatisfiesConstraintInput>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

These aliases will be picked up by the compiler to provide better names for the module instantiation predicates in the RA 😄 (which you know obviously).

let _ = if let Some(last) = vec_e.pop() // $ target=pop
{
opt_e = last.into(); // $ target=into
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Is there a purpose with the block here?

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

Copilot code reviewCopilotCopilot left review comments

@paldepindpaldepindpaldepind requested changes

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

no-change-note-requiredThis PR does not need a change noteRustPull requests that update Rust code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@hvitved@paldepind

[8]ページ先頭

©2009-2026 Movatter.jp