-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggest RUST_MIN_STACK
workaround on overflow
#122847
Suggest RUST_MIN_STACK
workaround on overflow
#122847
Conversation
@bors r+ rollup |
…ack-workaround-on-overflow, r=TaKO8Ki Suggest `RUST_MIN_STACK` workaround on overflow For some Rust crates, like p384, we can't do a whole lot about it even if the stack overflow is reported like in rust-lang#122357 because the problem may be inside LLVM or another codegen backend. We can, however, suggest people set a new `RUST_MIN_STACK` value while handling the SIGSEGV, as that stack-setting will carry forward into the dylib. As a bonus, this also leads to cleaning up the stack-setting code a bit.
…ack-workaround-on-overflow, r=TaKO8Ki Suggest `RUST_MIN_STACK` workaround on overflow For some Rust crates, like p384, we can't do a whole lot about it even if the stack overflow is reported like in rust-lang#122357 because the problem may be inside LLVM or another codegen backend. We can, however, suggest people set a new `RUST_MIN_STACK` value while handling the SIGSEGV, as that stack-setting will carry forward into the dylib. As a bonus, this also leads to cleaning up the stack-setting code a bit.
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#121619 (Experimental feature postfix match) - rust-lang#122370 (Gracefully handle `AnonConst` in `diagnostic_hir_wf_check()`) - rust-lang#122537 (interpret/allocation: fix aliasing issue in interpreter and refactor getters a bit) - rust-lang#122542 (coverage: Clean up marker statements that aren't needed later) - rust-lang#122800 (Add `NonNull::<[T]>::is_empty`.) - rust-lang#122820 (Stop using `<DefId as Ord>` in various diagnostic situations) - rust-lang#122847 (Suggest `RUST_MIN_STACK` workaround on overflow) - rust-lang#122855 (Fix Itanium mangling usizes) - rust-lang#122863 (add more ice tests ) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#122847 - workingjubilee:suggest-rust-min-stack-workaround-on-overflow, r=TaKO8Ki Suggest `RUST_MIN_STACK` workaround on overflow For some Rust crates, like p384, we can't do a whole lot about it even if the stack overflow is reported like in rust-lang#122357 because the problem may be inside LLVM or another codegen backend. We can, however, suggest people set a new `RUST_MIN_STACK` value while handling the SIGSEGV, as that stack-setting will carry forward into the dylib. As a bonus, this also leads to cleaning up the stack-setting code a bit.
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#121619 (Experimental feature postfix match) - rust-lang#122370 (Gracefully handle `AnonConst` in `diagnostic_hir_wf_check()`) - rust-lang#122537 (interpret/allocation: fix aliasing issue in interpreter and refactor getters a bit) - rust-lang#122542 (coverage: Clean up marker statements that aren't needed later) - rust-lang#122800 (Add `NonNull::<[T]>::is_empty`.) - rust-lang#122820 (Stop using `<DefId as Ord>` in various diagnostic situations) - rust-lang#122847 (Suggest `RUST_MIN_STACK` workaround on overflow) - rust-lang#122855 (Fix Itanium mangling usizes) - rust-lang#122863 (add more ice tests ) r? `@ghost` `@rustbot` modify labels: rollup
env::var_os("RUST_MIN_STACK") | ||
.map(|os_str| os_str.to_string_lossy().into_owned()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid the into_owned()
cloning:
env::var_os("RUST_MIN_STACK") | |
.map(|os_str| os_str.to_string_lossy().into_owned()) | |
env::var_os("RUST_MIN_STACK") | |
.as_ref() | |
.map(|os_str| os_str.to_string_lossy()) |
.filter(|s| s.trim() != "") | ||
.map(|s| s.trim().parse::<usize>().unwrap()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to .unwrap()
here? The UX on a bad RUST_MIN_STACK
wouldn't be great. Given the usage of .filter()
and .unwrap_or()
outside of this, does it mean we want to silently ignore bad values (e.g., RUST_MIN_STACK=" "
)?
.filter(|s| s.trim() != "") | |
.map(|s| s.trim().parse::<usize>().unwrap()) | |
.and_then(|s| s.trim().parse::<usize>().ok()) |
or, if we don't want to silently ignore the erroneous value:
.filter(|s| s.trim() != "") | |
.map(|s| s.trim().parse::<usize>().unwrap()) | |
.map(|s| s.trim().parse::<usize>().expect("`RUST_MIN_STACK` env var to be a `usize`)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thread 'main' panicked at compiler/rustc_interface/src/util.rs:61:48:
calledResult::unwrap()
on anErr
value: ParseIntError { kind: InvalidDigit }
Huh, I thought for some reason it'd look better than that.
Whoops didn't see the PR was already merged 😆 |
…t, r=compiler-errors defrost `RUST_MIN_STACK=ice rustc hello.rs` I didn't think too hard about testing my previous PR rust-lang#122847 which makes our stack overflow handler assist people in discovering the `RUST_MIN_STACK` variable (which apparently is surprisingly useful for Really Big codebases). After it was merged, some useful comments left in a drive-by review led me to discover I had added an ICE. This reworks the code a bit to explain the rationale, remove the ICE that I introduced, and properly test one of the diagnostics.
Rollup merge of rust-lang#125302 - workingjubilee:prefer-my-stack-neat, r=compiler-errors defrost `RUST_MIN_STACK=ice rustc hello.rs` I didn't think too hard about testing my previous PR rust-lang#122847 which makes our stack overflow handler assist people in discovering the `RUST_MIN_STACK` variable (which apparently is surprisingly useful for Really Big codebases). After it was merged, some useful comments left in a drive-by review led me to discover I had added an ICE. This reworks the code a bit to explain the rationale, remove the ICE that I introduced, and properly test one of the diagnostics.
For some Rust crates, like p384, we can't do a whole lot about it even if the stack overflow is reported like in #122357 because the problem may be inside LLVM or another codegen backend. We can, however, suggest people set a new
RUST_MIN_STACK
value while handling the SIGSEGV, as that stack-setting will carry forward into the dylib.As a bonus, this also leads to cleaning up the stack-setting code a bit.