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

Tracking issue: #160275

Fixes #93237

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

rustbot · 2026-08-05T11:55:48Z

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

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.

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