Skip to content

Limit obligation processing depth#153338

Open
Voultapher wants to merge 1 commit intorust-lang:mainfrom
Voultapher:limit-obligation-depth
Open

Limit obligation processing depth#153338
Voultapher wants to merge 1 commit intorust-lang:mainfrom
Voultapher:limit-obligation-depth

Conversation

@Voultapher
Copy link
Copy Markdown
Contributor

@Voultapher Voultapher commented Mar 3, 2026

Related to #152857

It's possible for ObligationForest::process_cycles to miss more complex cycles and this can lead to an endless fixpoint loop since it never reaches a settled state. It's desirable to adjust find_cycles_from_node to catch the cycle in
#152857. At the same time the nature of the code risks an endless loop by some other unexpected or unhandled cycle, so this PR aims to provide a basic limit to the depth of the loop.

The value of the constant was derived to be ~20x the highest value seen when compiling rustc itself. The top 10 values out of ~70 million invocations are:

┌───────┐
│ 10852 │
│ 10852 │
│ 10433 │
│ 10433 │
│ 10433 │
│ 10433 │
│ 8498  │
│ 8498  │
│ 6361  │
│ 6361  │
└───────┘

Related to rust-lang#152857

It's possible for `ObligationForest::process_cycles` to miss more
complex cycles and this can lead to an endless fixpoint loop since it
never reaches a settled state. It's desirable to adjust
`find_cycles_from_node` to catch the cycle in
rust-lang#152857. At the same time the
nature of the code risks an endless loop by some other unexpected or
unhandled cycle, so this PR aims to provide a basic limit to the depth
of the loop.

The value of the constant was derived to be ~20x the highest value seen
when compiling rustc itself. The top values are:

```
┌───────┐
│ 10852 │
│ 10852 │
│ 10433 │
│ 10433 │
│ 10433 │
│ 10433 │
│ 8498  │
│ 8498  │
│ 6361  │
│ 6361  │
└───────┘
```
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 3, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Mar 3, 2026

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 69 candidates
  • Random selection from 16 candidates

// It's possible for nodes to recursively add obligations in an endless cycle,
// for example https://github.com/rust-lang/rust/issues/152857.
self.error_at(index);
return outcome;
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Currently this creates an ICE, which strictly speaking is still preferable to an endless loop but I'd prefer to issue a better error something similar to the other overflow errors, but not sure what's the best way to do that here.

@fee1-dead
Copy link
Copy Markdown
Member

@rustbot reroll

@rustbot rustbot assigned madsmtm and unassigned fee1-dead Mar 9, 2026
@lqd
Copy link
Copy Markdown
Member

lqd commented Mar 9, 2026

cc @lcnr @oli-obk

@lcnr
Copy link
Copy Markdown
Contributor

lcnr commented Mar 9, 2026

Does it add new obligations at each step in the cycle? If so, we should make sure that we increase the recursion_limit of the newly added Obligation instead 🤔

@lcnr
Copy link
Copy Markdown
Contributor

lcnr commented Mar 9, 2026

r? lcnr

@rustbot rustbot assigned lcnr and unassigned madsmtm Mar 9, 2026
@lcnr
Copy link
Copy Markdown
Contributor

lcnr commented Mar 30, 2026

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 30, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Mar 30, 2026

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@Voultapher
Copy link
Copy Markdown
Contributor Author

@lcnr

Does it add new obligations at each step in the cycle?

Do you mean #152857 ? If so I'm not sure I fully understand how that suggestion relates to this proposed change. As described in the PR "At the same time the nature of the code risks an endless loop by some other unexpected or unhandled cycle, so this PR aims to provide a basic limit to the depth of the loop."

@lcnr
Copy link
Copy Markdown
Contributor

lcnr commented Apr 2, 2026

The reason this keeps on looping is that we set has_changed during every loop. Doing so should always increase some recursion_depth somewhere. Stating my question more clearly:

  • what is the obligation which sets has_changed and why does it do so?
  • i believe this obligation should then either have nested obligations with a higher recursion_depth or we should manually increment its own depth if it has to stick around

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

Labels

S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants