-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Add some track_caller info to precondition panics #129658
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
This comment has been minimized.
This comment has been minimized.
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Add some track_caller info to precondition panics r? `@ghost` Thought of this while looking at rust-lang#129642 (comment)
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (7798f9b): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (secondary -2.7%)This 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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResults (primary 0.1%, secondary 0.1%)This 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.
Bootstrap: 749.925s -> 752.783s (0.38%) |
That looks possibly acceptable. Let's just see how bad this becomes? @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Add some track_caller info to precondition panics r? `@ghost` Thought of this while looking at rust-lang#129642 (comment)
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (0e77a71): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never 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)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResults (primary 0.3%, secondary 0.1%)This 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.
Bootstrap: 749.925s -> 751.312s (0.18%) |
197c7b3
to
0c17bf5
Compare
This comment has been minimized.
This comment has been minimized.
0c17bf5
to
47937f2
Compare
This comment has been minimized.
This comment has been minimized.
7a90c3f
to
cd22e5f
Compare
Add some track_caller info to precondition panics Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful. I thought of this while looking at #129642 (comment). The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces. The perf implications of this are: * Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out. * The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU. * The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free.
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
@bors try |
Add some track_caller info to precondition panics Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful. I thought of this while looking at #129642 (comment). The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces. The perf implications of this are: * Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out. * The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU. * The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free. try-job: test-various
☀️ Try build successful - checks-actions |
@bors r=jhpratt |
☀️ Test successful - checks-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 45f256d (parent) -> be42293 (this PR) Test differencesShow 2448 test diffs2448 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard be422939446d7c5b27ba98debb6b4b8d6a261f1a --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (be42293): comparison URL. Overall result: ❌ regressions - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 1.0%, secondary 3.6%)This 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.
CyclesResults (primary 5.7%)This 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.
Binary sizeResults (primary 0.6%, secondary 1.3%)This 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.
Bootstrap: 779.523s -> 779.377s (-0.02%) |
Add some track_caller info to precondition panics Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful. I thought of this while looking at rust-lang#129642 (comment). The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces. The perf implications of this are: * Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out. * The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU. * The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free.
::core::panicking::panic_nounwind(concat!("unsafe precondition(s) violated: ", $message, | ||
let msg = concat!("unsafe precondition(s) violated: ", $message, | ||
"\n\nThis indicates a bug in the program. \ | ||
This Undefined Behavior check is optional, and cannot be relied on for safety.")); | ||
This Undefined Behavior check is optional, and cannot be relied on for safety."); | ||
::core::panicking::panic_nounwind_fmt(::core::fmt::Arguments::new_const(&[msg]), false); |
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.
This might be a slight (unoptimized?) codegen regression, for things as simple as (godbolt):
#[unsafe(no_mangle)]
pub fn r_next(mut r: std::ops::Range<usize>) -> Option<usize> {
r.next()
}
Before:
@alloc_3e1ebac14318b612ab4efabc52799932 = private unnamed_addr constant [186 x i8] c"unsafe precondition(s) violated: usize::unchecked_add cannot overflow\0A\0AThis indicates a bug in the program. This Undefined Behavior check is optional, and cannot be relied on for safety.", align 1
; <usize>::unchecked_add::precondition_check
define internal void @_RNvNvMs9_NtCs1p5UDGgVI4d_4core3numj13unchecked_add18precondition_checkCsb8r2Xq4BFYL_7example(i64 %lhs, i64 %rhs) unnamed_addr #0 {
; … (elided) …
bb1: ; preds = %start
; call core::panicking::panic_nounwind
call void @_ZN4core9panicking14panic_nounwind17h0c59dc9f7f043eadE(ptr align 1 @alloc_3e1ebac14318b612ab4efabc52799932, i64 186) #6
After:
@alloc_3e1ebac14318b612ab4efabc52799932 = private unnamed_addr constant [186 x i8] c"unsafe precondition(s) violated: usize::unchecked_add cannot overflow\0A\0AThis indicates a bug in the program. This Undefined Behavior check is optional, and cannot be relied on for safety.", align 1
; … (elided) …
; <usize>::unchecked_add::precondition_check
; Function Attrs: inlinehint nounwind nonlazybind uwtable
define internal void @_RNvNvMs9_NtCs25W7cjsTkyH_4core3numj13unchecked_add18precondition_checkCsgRHkggJuglA_7example(i64 %lhs, i64 %rhs, ptr align 8 %0) unnamed_addr #0 {
; … (elided) …
bb1: ; preds = %start
%2 = getelementptr inbounds nuw { ptr, i64 }, ptr %_6, i64 0
store ptr @alloc_3e1ebac14318b612ab4efabc52799932, ptr %2, align 8
; … (elided) …
; call core::panicking::panic_nounwind_fmt
call void @_ZN4core9panicking18panic_nounwind_fmt17h42ee446b0f35d307E(ptr align 8 %_4, i1 zeroext false, ptr align 8 %0) #6
Notably, even if we ignore the extra IR needed to implement fmt::Arguments::new_const
, the fact that &[msg]
is pointing to a stack array (as opposed to e.g. const { &[concat!(...)] }
) results in the constant string being stored on the stack at runtime.
(and unlike even &[concat!(...)]
, the let msg
blocks even incidental promotion)
That all aside, I am a bit surprised there isn't "just" a copy of panic_nounwind
that has #[track_caller]
, to avoid invoking panic_nounwind_fmt
and have this extra codegen (assuming it matters at all, ofc, I just noticed this in passing for unrelated reasons).
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.
@saethlin , pinging so you can see this
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 be clear, this is not that important or any kind of a blocker, I just found it slightly notable that runtime code is being unnecessarily generated, and arguably by mistake, even)
Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful.
I thought of this while looking at #129642 (comment).
The changes to
tests/ui/const*
happen because the const-eval interpreter skips#[track_caller]
frames in its backtraces.The perf implications of this are: