Increase the default stack size to 16 MiB and remove `ensure_sufficient_stack` by ChrisDenton · Pull Request #160535 · rust-lang/rust

ChrisDenton · 2026-08-05T01:05:33Z

View all comments

Tracking issue: #160275

Fixes #93237
Fixes #108499

rustbot · 2026-08-05T01:05:36Z

Some changes occurred in match checking

cc @Nadrieril

Some changes occurred in match lowering

cc @Nadrieril

changes to the core type system

cc @lcnr

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in exhaustiveness checking

cc @Nadrieril

rustbot · 2026-08-05T01:05:38Z

r? @petrochenkov

rustbot has assigned @petrochenkov.
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, types
compiler, types expanded to 75 candidates
Random selection from 20 candidates

ChrisDenton · 2026-08-05T01:08:59Z

Oh that pinged everyone, sorry. It does touch a lot of files but most of the +/- diff is whitespace changes.

rustbot · 2026-08-05T01:30:08Z

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @BoxyUwU

ChrisDenton · 2026-08-05T03:10:41Z

This test is fairly recent but I'm not sure that this it is still useful. It's basically testing the use of stacker, which is obsolete now.

View changes since the review

I suspect that this test might start failing again with increased scale of the test (e.g. if N=8000 fails at 3MiB, then at N=45000 it would fail at 16MiB.) But maybe making the scale here large enough makes the code itself impractical in other ways? 🤷

One thing I'm finding with these high recursion cases is that they start becoming very slow even before they approach the (new) stack limit. So we could increase the stack size further if there's a real world use case (which I don't see atm but not ruling out) but I think that might be sweeping the problem under the rug. I do feel that at the very least we should be warning about it if not treating it as a bug to be fixed.

bjorn3 · 2026-08-05T11:25:24Z

-    "windows_i686_msvc",
-    "windows_x86_64_gnu",
-    "windows_x86_64_gnullvm",
-    "windows_x86_64_msvc",


❤️ Helps with #156459

View changes since the review

petrochenkov · 2026-08-05T12:00:21Z

The implementation looks good to me.

Do you think this needs a whole team FCP in addition to the seconded MCP?
If not then r=me when CI is green.
@rustbot author
@bors rollup=never

ChrisDenton · 2026-08-05T12:34:25Z

Hm, I don't personally feel it needs an FCP in addition to the MCP but if someone thinks it should then I'm happy either way.

ChrisDenton · 2026-08-05T17:51:57Z

PR CI is green. Let's see what the full CI says

@bors r=petrochenkov

rust-bors · 2026-08-05T17:52:00Z

📌 Commit 967f720 has been approved by petrochenkov

It is now in the queue for this repository.

…=petrochenkov Increase the default stack size to 16 MiB and remove `ensure_sufficient_stack` Tracking issue: #160275 Fixes #93237

rust-bors · 2026-08-06T04:36:05Z

💔 Test for 145c517 failed: CI. Failed job:

auto - x86_64-gnu-llvm-21-3 (web logs, enhanced plaintext logs)

oli-obk · 2026-08-06T10:04:44Z

I guess some stack overflow regression test is not regressing anymore. Does that succeed spuriously (so it's close to the 16 MiB boundary?) or is it generally fixed?

ChrisDenton · 2026-08-06T10:22:34Z

I guess some stack overflow regression test is not regressing anymore. Does that succeed spuriously (so it's close to the 16 MiB boundary?) or is it generally fixed?

It succeeds on some runners but fails on others. I guess due to the particular optimisations they use. My thought is that doing mathematics in the type system is weird enough that asking the user to set RUST_MIN_STACK to some higher value is fine. Otherwise we could just increase the default stack size but I'm not sure it's worth it for this case.

In short I don't think this is a bug any more under the new system because the user now has options rather than needing us to fix it.

oli-obk · 2026-08-06T10:33:26Z

makes sense. Could turn it into a ui test with more stack or just remove it. Either way, can mark the issue as fixed by this PR.

oli-obk · 2026-08-06T10:33:48Z

r=me with the crash test handled $somehow

This crash test was for a bug in our use of `ensure_sufficient_stack`. Since that has now been removed, this test is redundant. Users can use the `RUST_MIN_STACK` environment variable instead if the default stack isn't sufficient.

ChrisDenton · 2026-08-06T12:02:45Z

I've removed it but if this merges then I'll comment on the original issue.

@bors r=petrochenkov,oli-obk

rust-bors · 2026-08-06T12:02:48Z

📌 Commit 402237c has been approved by petrochenkov,oli-obk

It is now in the queue for this repository.

rustbot assigned petrochenkov Aug 5, 2026

ChrisDenton changed the title ~~Remove ensure sufficient stack~~ Increase the stack size to 16 MiB and remove ensure sufficient stack Aug 5, 2026

ChrisDenton changed the title ~~Increase the stack size to 16 MiB and remove ensure sufficient stack~~ Increase the default stack size to 16 MiB and remove ensure sufficient stack Aug 5, 2026

ChrisDenton changed the title ~~Increase the default stack size to 16 MiB and remove ensure sufficient stack~~ Increase the default stack size to 16 MiB and remove ensure_sufficient_stack Aug 5, 2026