Rollup of 7 pull requests #92931
Closed
Rollup of 7 pull requests #92931
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
And to remove possibility of panics while changing the panic handler, because that resulted in a double panic.
Useful for thin wrapper attributes that are best passed as value instead of reference.
This hack was added in 6ab1f05. I don't know what change allowed removing the hack, but that commit added a test (which I presume covered the hack's behavior), and all tests are passing with this change. So, I think it should be good.
Inherent associated types *are* supported, just unstable.
This currently calls `std` a "crate" in one part of the message and a "module" in another part. The next commits fix this so it says "crate" in both places.
This allows simplifying a lot of code. It also fixes a subtle bug, exemplified by the test output changes.
Now that `res` is used directly, it seems the conditional is unnecessary.
I'm still not sure why this hack works so seemingly well.
These closures were quite complex and part of a quite complex function. The fact that they are closures makes mistakes likely when refactoring. For example, earlier, I meant to use `resolved`, an argument of the closure, but I instead typed `res`, which captured a local variable and caused a subtle bug that led to a confusing test failure. Extracting them as functions makes the code easier to understand and refactor.
includes minor refactorings
Implement `panic::update_hook`
Add a new function `panic::update_hook` to allow creating panic hooks that forward the call to the previously set panic hook, without race conditions. It works by taking a closure that transforms the old panic hook into a new one, while ensuring that during the execution of the closure no other thread can modify the panic hook. This is a small function so I hope it can be discussed here without a formal RFC, however if you prefer I can write one.
Consider the following example:
```rust
let prev = panic::take_hook();
panic::set_hook(Box::new(move |info| {
println!("panic handler A");
prev(info);
}));
```
This is a common pattern in libraries that need to do something in case of panic: log panic to a file, record code coverage, send panic message to a monitoring service, print custom message with link to github to open a new issue, etc. However it is impossible to avoid race conditions with the current API, because two threads can execute in this order:
* Thread A calls `panic::take_hook()`
* Thread B calls `panic::take_hook()`
* Thread A calls `panic::set_hook()`
* Thread B calls `panic::set_hook()`
And the result is that the original panic hook has been lost, as well as the panic hook set by thread A. The resulting panic hook will be the one set by thread B, which forwards to the default panic hook. This is not considered a big issue because the panic handler setup is usually run during initialization code, probably before spawning any other threads.
Using the new `panic::update_hook` function, this race condition is impossible, and the result will be either `A, B, original` or `B, A, original`.
```rust
panic::update_hook(|prev| {
Box::new(move |info| {
println!("panic handler A");
prev(info);
})
});
```
I found one real world use case here: https://github.com/dtolnay/proc-macro2/blob/988cf403e741aadfd5340bbf67e35e1062a526aa/src/detection.rs#L32 the workaround is to detect the race condition and panic in that case.
The pattern of `take_hook` + `set_hook` is very common, you can see some examples in this pull request, so I think it's natural to have a function that combines them both. Also using `update_hook` instead of `take_hook` + `set_hook` reduces the number of calls to `HOOK_LOCK.write()` from 2 to 1, but I don't expect this to make any difference in performance.
### Unresolved questions:
* `panic::update_hook` takes a closure, if that closure panics the error message is "panicked while processing panic" which is not nice. This is a consequence of holding the `HOOK_LOCK` while executing the closure. Could be avoided using `catch_unwind`?
* Reimplement `panic::set_hook` as `panic::update_hook(|_prev| hook)`?
…arth rustdoc: Yet more intra-doc links cleanup r? ```@Manishearth```
feat: rustc_pass_by_value lint attribute Useful for thin wrapper attributes that are best passed as value instead of reference. Fixes rust-lang#76935
…cs, r=camelid rustdoc: fix intra-link for generic trait impls fixes rust-lang#92662 r? ```@camelid```
…ron1011 Remove some unnecessary uses of `FieldDef::ident` Followup from rust-lang#92533. cc ```@Aaron1011``` ```@petrochenkov```
remove unused FIXME rust-lang#56935 seems to be fixed.
rustdoc: remove hand-rolled isatty This PR replaces bindings to the platform-specific isatty APIs with the `isatty` crate, as done elsewhere in the repository.
rustbot
added
T-compiler
|
@bors r+ rollup=never p=7 |
|
📌 Commit 96d0d0f has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 96d0d0f with merge 23de443a43aa1847f3677084cb58487b2652d0d7... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
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.
Successful merges:
panic::update_hook#92598 (Implementpanic::update_hook)FieldDef::ident#92799 (Remove some unnecessary uses ofFieldDef::ident)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup