Use #[track_caller] in const panic diagnostics. #87000
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It was already used for the message. This also uses it for the spans used for the error and backtrace.
m-ou-se
added
A-diagnostics
|
Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
|
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
oli-obk
reviewed
Jul 9, 2021
|
r? @oli-obk |
|
@bors r+ |
|
📌 Commit 0a4b53f has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 9, 2021
Rollup of 5 pull requests Successful merges: - rust-lang#86855 (Fix comments about unique borrows) - rust-lang#86881 (Inline implementation of lookup_line) - rust-lang#86937 (Change linked tracking issue for more_qualified_paths) - rust-lang#86994 (Update the comment on `lower_expr_try`) - rust-lang#87000 (Use #[track_caller] in const panic diagnostics.) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
RalfJung
reviewed
Jul 10, 2021
| .iter() | ||
| .rev() | ||
| .skip_while(|frame| frame.instance.def.requires_caller_location(*self.tcx)) | ||
| { |
There was a problem hiding this comment.
AFAIK this is also used for Miri error messages... do we really want those backtraces to skip frames? That sounds rather confusing. When we get a panic at runtime, with RUST_BACKTRACE we also show the full trace, not just the non-caller-location frames, right?
There was a problem hiding this comment.
Even during CTFE, while this makes sense for panics, note that this logic is used for all CTFE errors. I am not sure if that's always what we want.
There was a problem hiding this comment.
oh.. right. we should limit this to panics
There was a problem hiding this comment.
Turns out this is also the source of some Miri panics in our diagnostics code which didn't expect pruned backtraces.
If we want this kind of pruning, we should not to it in the lowest-level generate_stacktrace function.
RalfJung
reviewed
Jul 10, 2021
| .iter() | ||
| .rev() | ||
| .find(|frame| !frame.instance.def.requires_caller_location(*self.tcx)) | ||
| .map_or(self.tcx.span, |f| f.current_span()) |
There was a problem hiding this comment.
This function at least used to be hot, we should have done a perf run... oh well.
This was referenced Jun 26, 2022
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Jun 28, 2022
…li-obk interpret: do not prune requires_caller_location stack frames quite so early rust-lang#87000 made the interpreter skip `caller_location` frames for its stacktraces and `cur_span`. However, those functions are used for much more than just panic reporting, and e.g. when Miri reports UB somewhere, it probably wants to point inside `caller_location` frames. (And if it did not, it would want to have its own logic to decide that, not be forced into it by the core interpreter engine.) This fixes some rare ICEs in Miri that say "we should never pop more than one frame at once". So let's remove all `caller_location` logic from the core interpreter, and instead move it to CTFE error reporting. This does not change user-visible behavior. That's the first commit. We might additionally want to change CTFE error reporting to treat panics differently from other errors: only prune `caller_location` frames for panics. The second commit does that. But honestly I am not sure if this is an improvement. r? `@oli-obk`
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Jun 29, 2022
…li-obk interpret: do not prune requires_caller_location stack frames quite so early rust-lang#87000 made the interpreter skip `caller_location` frames for its stacktraces and `cur_span`. However, those functions are used for much more than just panic reporting, and e.g. when Miri reports UB somewhere, it probably wants to point inside `caller_location` frames. (And if it did not, it would want to have its own logic to decide that, not be forced into it by the core interpreter engine.) This fixes some rare ICEs in Miri that say "we should never pop more than one frame at once". So let's remove all `caller_location` logic from the core interpreter, and instead move it to CTFE error reporting. This does not change user-visible behavior. That's the first commit. We might additionally want to change CTFE error reporting to treat panics differently from other errors: only prune `caller_location` frames for panics. The second commit does that. But honestly I am not sure if this is an improvement. r? ``@oli-obk``
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change stops const panic diagnostics from reporting inside #[track_caller] functions by skipping over them.