Increase the default stack size to 16 MiB and remove ensure_sufficient_stack

[ChrisDenton]

View all comments

Tracking issue: #160275

Fixes #93237
Fixes #108499

[rustbot]

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]

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]

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

[rustbot]

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]

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

[nagisa]

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? 🤷

[ChrisDenton]

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]

❤️ Helps with #156459

View changes since the review

[rustbot]

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]

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]

@bors try job=aarch64

[rust-bors]

☀️ Try build successful (CI)
Build commit: 8d2078e (8d2078e2b31a7d1d809c9b5ec7225a330c7555df)
Base parent: 153ecc4 (153ecc4f74035b709bb3e1eb9546f1d934865042)

[ChrisDenton]

@bors r=petrochenkov,oli-obk

[rust-bors]

📌 Commit a84e1f0 has been approved by petrochenkov,oli-obk

It is now in the queue for this repository.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[ChrisDenton]

@bors r=petrochenkov,oli-obk

[rust-bors]

📌 Commit c7a664b has been approved by petrochenkov,oli-obk

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: petrochenkov,oli-obk
Duration: 3h 5m 19s
Pushing 811367e to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 969b803 (parent) -> 811367e (this PR)

Test differences

Show 164 test diffs

Stage 1

• [crashes] tests/crashes/108499.rs: pass -> [missing] (J0)
• [crashes] tests/crashes/93237.rs: pass -> [missing] (J0)

Stage 2

• [crashes] tests/crashes/108499.rs: pass -> [missing] (J1)
• [crashes] tests/crashes/93237.rs: pass -> [missing] (J1)

Additionally, 160 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: x86_64-gnu-llvm-21-3, x86_64-gnu-llvm-22-3
• J1: aarch64-apple-1, aarch64-apple-macos-26-1, aarch64-gnu, aarch64-gnu-llvm-21-1, aarch64-msvc-1, arm-android, armhf-gnu, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-gnu, x86_64-gnu-gcc, x86_64-gnu-llvm-21-2, x86_64-gnu-llvm-22-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 811367e98c08549865a32553076d617fb63154ef --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. dist-powerpc64-linux-gnu: 59m 51s -> 1h 31m (+53.1%)
2. dist-i686-msvc: 1h 21m -> 1h 55m (+42.3%)
3. x86_64-gnu-llvm-21-2: 1h 10m -> 1h 38m (+39.0%)
4. x86_64-gnu-llvm-22-1: 58m 16s -> 1h 16m (+31.8%)
5. optional-x86_64-gnu-autodiff: 41m 34s -> 53m 35s (+28.9%)
6. tidy: 2m 45s -> 1m 57s (-28.9%)
7. arm-android: 1h 21m -> 1h 43m (+27.7%)
8. dist-riscv64-linux-musl: 1h 3m -> 1h 21m (+27.6%)
9. x86_64-gnu: 2h 40m -> 1h 56m (-27.4%)
10. dist-riscv64-linux-gnu: 1h 9m -> 1h 26m (+25.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (811367e): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.9%	[0.9%, 0.9%]	6
Improvements ✅ (primary)	-0.5%	[-1.8%, -0.2%]	183
Improvements ✅ (secondary)	-0.8%	[-2.9%, -0.2%]	209
All ❌✅ (primary)	-0.5%	[-1.8%, -0.2%]	183

Max RSS (memory usage)

Results (primary -2.2%, secondary -1.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.0%	[1.8%, 2.3%]	2
Improvements ✅ (primary)	-2.2%	[-2.2%, -2.2%]	1
Improvements ✅ (secondary)	-1.4%	[-5.6%, -0.5%]	19
All ❌✅ (primary)	-2.2%	[-2.2%, -2.2%]	1

Cycles

Results (primary -2.3%, secondary -1.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.8%	[0.5%, 1.0%]	4
Improvements ✅ (primary)	-2.3%	[-2.3%, -2.3%]	1
Improvements ✅ (secondary)	-2.0%	[-5.5%, -0.4%]	34
All ❌✅ (primary)	-2.3%	[-2.3%, -2.3%]	1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 458.441s -> 456.009s (-0.53%)
Artifact size: 398.59 MiB -> 396.12 MiB (-0.62%)