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

Simplify on_panic callback handling #28585

Merged
merged 2 commits into from
Sep 23, 2015
Merged

Conversation

ranma42
Copy link
Contributor

@ranma42 ranma42 commented Sep 22, 2015

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.

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
Copy link
Collaborator

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member

Actually while you're at it, could you remove the unwind::register function (and the callback array) altogether? They're from an era long since passed and shouldn't be necessary any more.

Thanks for the cleanups!

@ranma42
Copy link
Contributor Author

ranma42 commented Sep 22, 2015

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).
@ranma42
Copy link
Contributor Author

ranma42 commented Sep 22, 2015

I updated this PR. I'll make another one soon to make panicking more robust (in particular, to make sure that if on_panic panics, it does not end up in an infinite recursion and correctly aborts at the double panic)

@alexcrichton
Copy link
Member

@bors: r+ c6d277a

Thanks! I wouldn't go to too much effort to ensure that recursive panics like that don't lead to bugs, they're pretty rare the all code run is contained in the standard library so it's easy to audit. If the fix is relatively lightweight, however, seems fine to me!

@bors
Copy link
Contributor

bors commented Sep 23, 2015

⌛ Testing commit c6d277a with merge 07ca1ab...

bors added a commit that referenced this pull request Sep 23, 2015
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.
@bors bors merged commit c6d277a into rust-lang:master Sep 23, 2015
@ranma42 ranma42 deleted the simpler-panic branch September 23, 2015 13:25
nnethercote added a commit to nnethercote/rust that referenced this pull request Nov 9, 2023
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.
nnethercote added a commit to nnethercote/rust that referenced this pull request Nov 10, 2023
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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 10, 2023
…=<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`
TaKO8Ki added a commit to TaKO8Ki/rust that referenced this pull request Nov 13, 2023
… 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`
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 13, 2023
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`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants