Skip to content
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

Panic machinery comments and tweaks #66766

Merged
merged 8 commits into from
Nov 30, 2019
Merged

Conversation

RalfJung
Copy link
Member

This is mostly more comments, but I also renamed some things:

  • BoxMeUp::box_me_up is not terribly descriptive, and since this is a "take"-style method (the argument is &mut self but the return type is fully owned, even though you can't tell from the type) I chose a name involving "take".
  • continue_panic_fmt was very confusing as it was entirely unclear what was being continued -- for some time I thought "continue" might be the same as "resume" for a panic, but that's something entirely different. So I renamed this to begin_panic_handler, matching the begin_panic* theme of the other entry points.

r? @Dylan-DPC @SimonSapin

…andler] directly

The "continue" in the name was really confusing; it sounds way too much like "resume" which is a totally different concept around panics.
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 26, 2019
let data = match self.inner.take() {
Some(a) => Box::new(a) as Box<dyn Any + Send>,
None => Box::new(()),
None => Box::new(()), // this should never happen: we got called twice
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering if it is appropriate to call process::abort() here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe. I feel it’s not very important since this is a private API that has exactly one call site.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me re-phrase my question: is there any reason not to do that? Is there any legitimate use of this interface that calls take_box twice?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually what I am wondering about even more is what the method does not take self by-value?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an impl for a private type PanicPayload, whose value is only ever constructed in one place. A pointer to that value is __rust_start_panic, which we can consider a private implementation detail of the standard library. So both the definition and all uses of this API (all one of them) are under our control. So it doesn’t matter in my opinion what the code does in situations that we know never happen. There is no reason to abort, and there is no reason not to abort. Feel free to change this to abort if you’d like, I don’t mind r+’ing that change.

This method cannot take self by value because it is (only, ever) called by src/libpanic_unwind/lib.rs’s __rust_start_panic which dereferences a raw pointer (cast from usize) to get &mut &mut dyn BoxMeUp. It cannot (easily) be an owned Box<dyn BoxMeUp> because libpanic_unwind doesn’t depend on liballoc which defines Box. Oh and for the trait to be object-safe it might have to be self: Box<Self> or something.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It cannot (easily) be an owned Box because libpanic_unwind doesn’t depend on liballoc which defines Box

Ah, thanks, I added a comment along those lines (and made it abort). Please check.

Copy link
Contributor

@SimonSapin SimonSapin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"continue" made some sense to me since it was called after "begin", but I like this new structure better. Thanks!

r=me with one code comment tweak

@@ -459,7 +458,9 @@ fn rust_panic_with_hook(payload: &mut dyn BoxMeUp,
match HOOK {
// Some platforms know that printing to stderr won't ever actually
// print anything, and if that's the case we can skip the default
// hook.
// hook. Since string formatting happens lazily when calling `payload`
// methods, this means that with libpanic_abort, we don't format
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

panic_output().is_none() does not indicate libpanic_abort. It indicates a target such as wasm that doesn’t have anything like stderr, so we can’t print a message at all.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, with libpanic_unwind we call take_box() which will still trigger the formatting.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right, I see what you meant now.

@SimonSapin
Copy link
Contributor

Looks good, thanks!

@bors r+

@bors
Copy link
Contributor

bors commented Nov 26, 2019

📌 Commit 4a19ef9 has been approved by SimonSapin

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 26, 2019
@RalfJung
Copy link
Member Author

@bors r-

@SimonSapin it was pointed out to me on reddit that I forgot about one entry point, so I proposed a better name for that one as well. What do you think? This mirrors rust_panic_with_hook.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 26, 2019
@Dylan-DPC-zz
Copy link

r? @SimonSapin

@SimonSapin
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Nov 26, 2019

📌 Commit babe9fc has been approved by SimonSapin

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 26, 2019
RalfJung added a commit to RalfJung/rust that referenced this pull request Nov 29, 2019
Panic machinery comments and tweaks

This is mostly more comments, but I also renamed some things:
* `BoxMeUp::box_me_up` is not terribly descriptive, and since this is a "take"-style method (the argument is `&mut self` but the return type is fully owned, even though you can't tell from the type) I chose a name involving "take".
* `continue_panic_fmt` was very confusing as it was entirely unclear what was being continued -- for some time I thought "continue" might be the same as "resume" for a panic, but that's something entirely different. So I renamed this to `begin_panic_handler`, matching the `begin_panic*` theme of the other entry points.

r? @Dylan-DPC @SimonSapin
RalfJung added a commit to RalfJung/rust that referenced this pull request Nov 29, 2019
Panic machinery comments and tweaks

This is mostly more comments, but I also renamed some things:
* `BoxMeUp::box_me_up` is not terribly descriptive, and since this is a "take"-style method (the argument is `&mut self` but the return type is fully owned, even though you can't tell from the type) I chose a name involving "take".
* `continue_panic_fmt` was very confusing as it was entirely unclear what was being continued -- for some time I thought "continue" might be the same as "resume" for a panic, but that's something entirely different. So I renamed this to `begin_panic_handler`, matching the `begin_panic*` theme of the other entry points.

r? @Dylan-DPC @SimonSapin
bors added a commit that referenced this pull request Nov 29, 2019
Rollup of 11 pull requests

Successful merges:

 - #66379 (Rephrase docs in for ptr)
 - #66589 (Draw vertical lines correctly in compiler error messages)
 - #66613 (Allow customising ty::TraitRef's printing behavior)
 - #66766 (Panic machinery comments and tweaks)
 - #66791 (Handle GlobalCtxt directly from librustc_interface query system)
 - #66793 (Record temporary static references in generator witnesses)
 - #66808 (Cleanup error code)
 - #66826 (Clarifies how to tag users for assigning PRs)
 - #66837 (Clarify `{f32,f64}::EPSILON` docs)
 - #66844 (Miri: do not consider memory allocated by caller_location leaked)
 - #66872 (Minor documentation fix)

Failed merges:

r? @ghost
@bors bors merged commit babe9fc into rust-lang:master Nov 30, 2019
@RalfJung RalfJung deleted the panic-comments branch November 30, 2019 07:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants