Implement Default for AssertUnwindSafe

[SoniEx2]

Trait impls are still insta-stable yeah...?

[rust-highfive]

Thank you for submitting a new PR for the library teams! If this PR contains a stabilization of a library feature that has not already completed FCP in its tracking issue, introduces new or changes existing unstable library APIs, or changes our public documentation in ways that create new stability guarantees then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @scottmcm (or someone else) soon.

Please see the contribution instructions for more information.

[SoniEx2]

r? rust-lang/libs-api @rustbot label +T-libs-api

[m-ou-se]

Thanks for your PR.

Do you have an example or use case for this? When is it useful for AssertUnwindSafe to implement Default?

[SoniEx2]

We have this "beauty": https://docs.rs/hexchat-unsafe-plugin/1.0.0/src/hexchat_unsafe_plugin/lib.rs.html#1143 (it is a bit ugly, but anyway)

Altho it was pretty easy to work around it: https://docs.rs/hexchat-unsafe-plugin/1.0.0/src/hexchat_unsafe_plugin/lib.rs.html#1361

(We put the AssertUnwindSafe on the RefCell rather than Rc so we could easily Rc::clone(&it) and it's not disruptive to calling .borrow() or .borrow_mut() on it)

Edit: We do believe it would help with clarity to use Contexts::default(). And there's no benefit to making a full wrapper type just for a Default impl here (we would even argue it'd bring drawbacks).

[m-ou-se]

@rfcbot merge

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[m-ou-se]

@bors r+ rollup

[bors]

📌 Commit 8d5a496 has been approved by m-ou-se

[Mark-Simulacrum]

This was probably a perf regression (marking from the upstream PR which actually merged this).

Rollup of 8 pull requests #96428
(Comparison Link)

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count	7	2	1	0	8
mean	1.3%	0.3%	-0.4%	N/A	1.1%
max	1.8%	0.3%	-0.4%	N/A	1.8%

Looks likely to be related to the new impl Default for AssertUnwindSafe, though
detailed query pages do not reflect the regressions. Marking the regression as
triaged, because it's unlikely we would want to revert the impl at this point.
However, it's probably the case that impls for public standard library types may
want to avoid being rolled up, as they can influence downstream performance
across both rustdoc and regular compilation.

[SoniEx2]

Diesel does throw trait resolution into overdrive... but we're surprised impl Default for AssertUnwindSafe out of all things turns out to be relevant here o.o

wonder how that happens.