[scip] "thread 'main' has overflowed its stack" since nightly-2025-01-21

[glandium]

Steps to reproduce:

• Clone https://hg.mozilla.org/mozilla-central (mercurial) or https://github.com/mozilla/gecko-dev (git)
• Presumably, this would be reproductible with what you get out of the clone, but just in case, checkout 4d679baa3086ad410eb22618e50aea045424c0de (mercurial) or 3ee2e63c1b9cff116ff7bec1189e99fab6e1c15c (git)
• Copy .cargo/config.toml.in to .cargo/config.toml.
• Run rust-analyzer scip .

This is a serious regression in nightly and it's important to fix it before the next release.

Bad: rust-analyzer 1.86.0-nightly (f3d1d47 2025-01-20)
Good: rust-analyzer 1.86.0-nightly (9a1d156 2025-01-19)
... but of course the commits shown there are not from rust-analyzer itself... and it's not a submodule.

I /think/ the good one is 7b368b9 and the bad one is 93a5846.

[glandium]

Bisected to 5530167 (#18925)
Cc: @Veykril

[lnicola]

I was doing the same bisection and ended up on the same commit.

Anyway, my suggestion is to use our binaries from GitHub Releases instead of those in rustup. They're updated more often, and make it easier to switch versions or mix and match toolchains and rust-analyzer.

[glandium]

It looks like it's entering an infinitely recursive loop.

backtrace

[ShoyuVanilla]

I guess it's not an infinite loop, but a type with very complicated projection type bounds(not sure whether this bound inference is a bug or not) that large enough to blow off the stack.
Maybe we should implement a hard limit on display depth or something like a display context and smartly handle recurring bounds

[glandium]

Well, multiplying the stack size by 10 yields a 119583 frames deep backtrace... How complicated is that projection, really?

[glandium]

And a 1.19M frames backtrace with a 800M stack. If it's not an infinite recursion, it's close enough...

[ShoyuVanilla]

I guessed so while reading the backtrace you've attached; it indeed looped inside a cyclic graph between three functions inside hir-ty/src/display.rs like hell but in the end it exited the loop and crashed in chalk call stacks.

So, I thought that might not be an infinite loop.

But of course, it might fall into another bigger loop after that chalk call stacks or the monstrous projection bound might be a some kind of bug.

I'll check what type with projection bounds caused this and find out the exact reason

[glandium]

The first 94 frames in the backtrace I attached are kind of a red herring. What happens is that entering the new branch runs code that uses a bunch of stack, finishes, then the code gets to recurse. The recursed code enters the new branch again, using a bunch of stack, finishing, then recurses again. Rinse, repeat. Each recursion bumps the stack a little, and some point, when entering the new branch again, there's not enough stack to run the code before the recursion. That's where the crash happens, but it's kind of irrelevant.

[ShoyuVanilla]

Oh, I see. It looks like a infinite recursion while resolving some projection bounds. Thanks!