nicer errors from assert_unsafe_precondition#102732
Conversation
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
|
(rust-highfive has picked a reviewer for you, use r? to override) |
04ac775 to
e4a8e33
Compare
|
The Miri subtree was changed cc @rust-lang/miri |
|
I extended this to a slight refactor of the no-unwind part of the core::panicking module, so that we can get a nicer error message. |
library/core/src/panicking.rs
Outdated
There was a problem hiding this comment.
I hope I got all these attributes right. :D They are basically copied from panic_fmt.
This comment has been minimized.
This comment has been minimized.
|
Ah, looks like that codegen test wants things to be inlined when |
|
... but of course when we call it elsewhere we don't want it to be inlined. There's no way to force inlining for one but not all call sites, is there? |
e4a8e33 to
d772a6d
Compare
This comment has been minimized.
This comment has been minimized.
d772a6d to
663b6ba
Compare
library/core/src/intrinsics.rs
Outdated
There was a problem hiding this comment.
If you give a moose a muffin...
Can we stringify the predicate and pass that instead?
There was a problem hiding this comment.
I think I'd be in favor of letting the macro user give a string. But that's for a future PR, first this one needs to work.
This comment has been minimized.
This comment has been minimized.
|
Yeah I am out of ideas here for how to make that test pass... |
|
@bjorn3 any idea how to make progress here? |
|
Maybe just accept code duplication between the two functions? |
|
Is that really the beet we can do? Sounds terrible.^^ |
|
I think the actual problem here is that this implementation fails the goal of reducing code size impact in the caller: You are passing in a This is probably also how it ends up failing the stack protector test. |
|
I shouldn't be passing anything if that all gets inlined. And both the code before and after this PR construct a ... so, I do not understand how this can make a difference. But I'll try your suggestion. |
604ddf3 to
38c78a9
Compare
|
@bors r=bjorn3 |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (538f118): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
|
@rustbot label: +perf-regression-triaged |
…n3, r=thomcc
Even nicer errors from assert_unsafe_precondition
For example, now running `cargo test` with this patch I get things like:
```
$ cargo +stage1 test
Finished test [unoptimized + debuginfo] target(s) in 0.01s
Running unittests src/lib.rs (target/debug/deps/malloc_buf-9d105ddf86862995)
running 5 tests
thread 'tests::test_null_buf' panicked at 'unsafe precondition violated: is_aligned_and_not_null(data) &&
crate::mem::size_of::<T>().saturating_mul(len) <= isize::MAX as usize', /home/ben/rust/library/core/src/slice/raw.rs:93:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread panicked while panicking. aborting.
error: test failed, to rerun pass `--lib`
Caused by:
process didn't exit successfully: `/tmp/malloc_buf-1.0.0/target/debug/deps/malloc_buf-9d105ddf86862995` (signal: 6, SIGABRT: process abort signal)
```
This is still not perfect, but these are better for another PR:
* `stringify!` is trying to do clever pretty-printing on the `expr` inside `assert_unsafe_precondition` and can even add a newline.
* It would be nice to print a bit more information about where the problem is. Perhaps this is `cfg_attr(debug_assertions, track_caller)`, or perhaps it the function name added to `Location`.
cc `@RalfJung` this is what I was thinking of for rust-lang#102732 (comment)
…n3, r=thomcc
Even nicer errors from assert_unsafe_precondition
For example, now running `cargo test` with this patch I get things like:
```
$ cargo +stage1 test
Finished test [unoptimized + debuginfo] target(s) in 0.01s
Running unittests src/lib.rs (target/debug/deps/malloc_buf-9d105ddf86862995)
running 5 tests
thread 'tests::test_null_buf' panicked at 'unsafe precondition violated: is_aligned_and_not_null(data) &&
crate::mem::size_of::<T>().saturating_mul(len) <= isize::MAX as usize', /home/ben/rust/library/core/src/slice/raw.rs:93:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread panicked while panicking. aborting.
error: test failed, to rerun pass `--lib`
Caused by:
process didn't exit successfully: `/tmp/malloc_buf-1.0.0/target/debug/deps/malloc_buf-9d105ddf86862995` (signal: 6, SIGABRT: process abort signal)
```
This is still not perfect, but these are better for another PR:
* `stringify!` is trying to do clever pretty-printing on the `expr` inside `assert_unsafe_precondition` and can even add a newline.
* It would be nice to print a bit more information about where the problem is. Perhaps this is `cfg_attr(debug_assertions, track_caller)`, or perhaps it the function name added to `Location`.
cc ``@RalfJung`` this is what I was thinking of for rust-lang#102732 (comment)
…, r=bjorn3 nicer errors from assert_unsafe_precondition This makes the errors shown by cargo-careful nicer, and since `panic_no_unwind` is `nounwind noreturn` it hopefully doesn't have bad codegen impact. Thanks to `@bjorn3` for the hint! Would be nice if we could somehow supply our own (static) message to print, currently it always prints `panic in a function that cannot unwind`. But still, this is better than before.
Even nicer errors from assert_unsafe_precondition
For example, now running `cargo test` with this patch I get things like:
```
$ cargo +stage1 test
Finished test [unoptimized + debuginfo] target(s) in 0.01s
Running unittests src/lib.rs (target/debug/deps/malloc_buf-9d105ddf86862995)
running 5 tests
thread 'tests::test_null_buf' panicked at 'unsafe precondition violated: is_aligned_and_not_null(data) &&
crate::mem::size_of::<T>().saturating_mul(len) <= isize::MAX as usize', /home/ben/rust/library/core/src/slice/raw.rs:93:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread panicked while panicking. aborting.
error: test failed, to rerun pass `--lib`
Caused by:
process didn't exit successfully: `/tmp/malloc_buf-1.0.0/target/debug/deps/malloc_buf-9d105ddf86862995` (signal: 6, SIGABRT: process abort signal)
```
This is still not perfect, but these are better for another PR:
* `stringify!` is trying to do clever pretty-printing on the `expr` inside `assert_unsafe_precondition` and can even add a newline.
* It would be nice to print a bit more information about where the problem is. Perhaps this is `cfg_attr(debug_assertions, track_caller)`, or perhaps it the function name added to `Location`.
cc ``@RalfJung`` this is what I was thinking of for rust-lang/rust#102732 (comment)
This makes the errors shown by cargo-careful nicer, and since
panic_no_unwindisnounwind noreturnit hopefully doesn't have bad codegen impact. Thanks to @bjorn3 for the hint!Would be nice if we could somehow supply our own (static) message to print, currently it always prints
panic in a function that cannot unwind. But still, this is better than before.