-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Simplify on_panic callback handling #28585
Conversation
The registration of `panicking::on_panic` as a general-purpose callback is overcomplicated and can fail. Instead, invoking it explicitly removes the need for locking and paves the way for further improvements.
(rust_highfive has picked a reviewer for you, use r? to override) |
Actually while you're at it, could you remove the Thanks for the cleanups! |
Wow, I dod not expect that to already be possible, but I'm very glad to do that. More patches incoming :) |
The `register` function is unstable and it is not used anymore, hence it can be removed (together with the now-unused `Callback` type and `static` variables).
I updated this PR. I'll make another one soon to make panicking more robust (in particular, to make sure that if |
This is part of some cleanup I did while investigating #28129. This also ensures that `on_panic` is run even if the user has registered too many callbacks.
It was added way back in rust-lang#28585 under the name `-Zkeep-mtwt-tables`. The justification was: > This is so that the resolution results can be used after analysis, > potentially for tool support. There are no uses of significance in the code base, and various Google searches for both option names (and variants) found nothing of interest. I think this can safely be removed.
It was added way back in rust-lang#28585 under the name `-Zkeep-mtwt-tables`. The justification was: > This is so that the resolution results can be used after analysis, > potentially for tool support. There are no uses of significance in the code base, and various Google searches for both option names (and variants) found nothing of interest. @petrochenkov says removing this part (and it's only part) of the hygiene data is dubious. It doesn't seem that big, so let's just keep it around.
…=<try> Remove `-Zkeep-hygiene-data`. It was added way back in rust-lang#28585 under the name `-Zkeep-mtwt-tables`. The justification was: > This is so that the resolution results can be used after analysis, > potentially for tool support. There are no uses of significance in the code base, and various Google searches for both option names (and variants) found nothing of interest. I think this can safely be removed. r? `@davidtwco`
… r=petrochenkov Remove `-Zkeep-hygiene-data`. It was added way back in rust-lang#28585 under the name `-Zkeep-mtwt-tables`. The justification was: > This is so that the resolution results can be used after analysis, > potentially for tool support. There are no uses of significance in the code base, and various Google searches for both option names (and variants) found nothing of interest. I think this can safely be removed. r? `@davidtwco`
Rollup merge of rust-lang#117737 - nnethercote:rm-Zkeep-hygiene-data, r=petrochenkov Remove `-Zkeep-hygiene-data`. It was added way back in rust-lang#28585 under the name `-Zkeep-mtwt-tables`. The justification was: > This is so that the resolution results can be used after analysis, > potentially for tool support. There are no uses of significance in the code base, and various Google searches for both option names (and variants) found nothing of interest. I think this can safely be removed. r? `@davidtwco`
This is part of some cleanup I did while investigating #28129.
This also ensures that
on_panic
is run even if the user has registered too many callbacks.