-
Notifications
You must be signed in to change notification settings - Fork 13.8k
Clarify how to remediate the panic_immediate_abort error #147470
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
Conversation
Users who build `core` for the sole purpose of enabling `panic_immediate_abort` might expect "`panic_immediate_abort` is now a real panic strategy" to mean that setting `panic = "immediate-abort"` in `Cargo.toml` or `-Cpanic=immediate-abort` in `RUSTFLAGS` to be sufficient for migration. But this is not the case, `core` still needs to be built for those changes to take effect. See rust-lang#146974 for additional context.
rustbot has assigned @Mark-Simulacrum. Use |
I'm not libs so I can't actually approve this, unfortunately. I wrote the original error because I was thinking of having added to the |
@bors r+ rollup |
…crum Clarify how to remediate the panic_immediate_abort error Users who build `core` for the sole purpose of enabling `panic_immediate_abort` might expect "`panic_immediate_abort` is now a real panic strategy" to mean that setting `panic = "immediate-abort"` in `Cargo.toml` or `-Cpanic=immediate-abort` in `RUSTFLAGS` to be sufficient for migration. But this is not the case, `core` still needs to be built for those changes to take effect. See rust-lang#146974 for additional context. See rust-lang#147286 and rust-lang/cargo#16042 for the revelant tracking issues.
Rollup of 6 pull requests Successful merges: - #143900 ([rustdoc] Correctly handle `should_panic` doctest attribute and fix `--no-run` test flag on the 2024 edition) - #147420 (Add diagnostic items for `pub mod consts` of FP types) - #147467 (Fix double warnings on `#[no_mangle]`) - #147470 (Clarify how to remediate the panic_immediate_abort error) - #147480 (Do not invalidate CFG caches in CtfeLimit.) - #147481 (format: some small cleanup) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 12 pull requests Successful merges: - #146568 (Port the implemention of SIMD intrinsics from Miri to const-eval) - #147373 (give a better example why `std` modules named like primitives are needed) - #147419 (bootstrap: add `Builder::rustc_cmd` that includes the lib path) - #147420 (Add diagnostic items for `pub mod consts` of FP types) - #147457 (specialize slice::fill to use memset when possible) - #147467 (Fix double warnings on `#[no_mangle]`) - #147470 (Clarify how to remediate the panic_immediate_abort error) - #147480 (Do not invalidate CFG caches in CtfeLimit.) - #147481 (format: some small cleanup) - #147488 (refactor: Remove `LLVMRustInsertPrivateGlobal` and `define_private_global`) - #147489 (Prefer to use repeat_n over repeat().take()) - #147506 (compiletest: Isolate public APIs and minimize public surface area) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #147470 - ia0:immediate-abort, r=Mark-Simulacrum Clarify how to remediate the panic_immediate_abort error Users who build `core` for the sole purpose of enabling `panic_immediate_abort` might expect "`panic_immediate_abort` is now a real panic strategy" to mean that setting `panic = "immediate-abort"` in `Cargo.toml` or `-Cpanic=immediate-abort` in `RUSTFLAGS` to be sufficient for migration. But this is not the case, `core` still needs to be built for those changes to take effect. See #146974 for additional context. See #147286 and rust-lang/cargo#16042 for the revelant tracking issues.
Users who build
core
for the sole purpose of enablingpanic_immediate_abort
might expect "panic_immediate_abort
is now a real panic strategy" to mean that settingpanic = "immediate-abort"
inCargo.toml
or-Cpanic=immediate-abort
inRUSTFLAGS
to be sufficient for migration. But this is not the case,core
still needs to be built for those changes to take effect.See #146974 for additional context.
See #147286 and rust-lang/cargo#16042 for the revelant tracking issues.