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

Tracking Issue for impl UnwindSafe/RefUnwindSafe for Condvar #121690

Closed
3 tasks
ecton opened this issue Feb 27, 2024 · 8 comments
Closed
3 tasks

Tracking Issue for impl UnwindSafe/RefUnwindSafe for Condvar #121690

ecton opened this issue Feb 27, 2024 · 8 comments
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@ecton
Copy link
Contributor

ecton commented Feb 27, 2024

The feature gate for the issue is #![feature(unwindsafe_condvar)].

This is a tracking issue for implementing core::panic::UnwindSafe and core::panic::RefUnwindSafe for std::sync::Condvar.

Currently, UnwindSafe and RefUnwindSafe are only implemented for some targets (See #118009). It was suggested a PR could be submitted to fix this inconsistency. However, in looking at how Mutex and RwLock get their unwind safety, I decided the best course of action would be to add the impl right next to those similar implementations:

#[stable(feature = "catch_unwind", since = "1.9.0")]
impl<T: ?Sized> UnwindSafe for Mutex<T> {}
#[stable(feature = "catch_unwind", since = "1.9.0")]
impl<T: ?Sized> UnwindSafe for RwLock<T> {}
#[stable(feature = "unwind_safe_lock_refs", since = "1.12.0")]
impl<T: ?Sized> RefUnwindSafe for Mutex<T> {}
#[stable(feature = "unwind_safe_lock_refs", since = "1.12.0")]
impl<T: ?Sized> RefUnwindSafe for RwLock<T> {}

By adding the implementation this way, my understanding is that the first step is submitting this tracking issue because impls are insta-stable.

Steps

  • Add the two implementations
  • Final comment period (FCP)
  • Stabilization PR

Unresolved Questions

  • Are the implementations on all targets unwind safe? I'm the original reporter of the issue, and was encouraged to submit a PR, but I don't actually know if all of the implementations are actually unwind safe.
@ecton ecton added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Feb 27, 2024
@Noratrieb
Copy link
Member

We don't use tracking issues for impls exactly because they are insta stable. Tracking issues are for tracking the state of merged unstable features.

@jieyouxu jieyouxu added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Feb 27, 2024
@ecton
Copy link
Contributor Author

ecton commented Feb 27, 2024

We don't use tracking issues for impls exactly because they are insta stable. Tracking issues are for tracking the state of merged unstable features.

So how do I resolve this error:

 error: an `#[unstable]` annotation here has no effect
  --> library/std/src/panic.rs:70:1
   |
70 | #[unstable(feature = "unwindsafe_condvar", issue = "118009")]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #55436 <https://github.com/rust-lang/rust/issues/55436> for more information
   = note: `#[deny(ineffective_unstable_trait_impl)]` on by default

In other words: how do I submit a PR that isn't broken if I don't have a tracking feature name for this impl block? Or do you disagree that this is the way it should be implemented?

@ecton
Copy link
Contributor Author

ecton commented Feb 27, 2024

In case it wasn't clear how I was suggesting the change, it's simply to add the two impls side-by-side with the other synchronization primitives:

index 3728d5b64b8..6b4105bd91d 100644
--- a/library/std/src/panic.rs
+++ b/library/std/src/panic.rs
@@ -6,7 +6,7 @@
 use crate::collections;
 use crate::panicking;
 use crate::sync::atomic::{AtomicU8, Ordering};
-use crate::sync::{Mutex, RwLock};
+use crate::sync::{Condvar, Mutex, RwLock};
 use crate::thread::Result;
 
 #[doc(hidden)]
@@ -67,11 +67,15 @@ pub fn panic_any<M: 'static + Any + Send>(msg: M) -> ! {
 impl<T: ?Sized> UnwindSafe for Mutex<T> {}
 #[stable(feature = "catch_unwind", since = "1.9.0")]
 impl<T: ?Sized> UnwindSafe for RwLock<T> {}
+#[unstable(feature = "unwindsafe_condvar", issue = "118009")]
+impl UnwindSafe for Condvar {}
 
 #[stable(feature = "unwind_safe_lock_refs", since = "1.12.0")]
 impl<T: ?Sized> RefUnwindSafe for Mutex<T> {}
 #[stable(feature = "unwind_safe_lock_refs", since = "1.12.0")]
 impl<T: ?Sized> RefUnwindSafe for RwLock<T> {}
+#[unstable(feature = "unwindsafe_condvar", issue = "118009")]
+impl RefUnwindSafe for Condvar {}
 
 // https://github.com/rust-lang/rust/issues/62301
 #[stable(feature = "hashbrown", since = "1.36.0")]

Without the #[unstable] attribute, I get this error when building:

error: implementation has missing stability attribute
  --> library/std/src/panic.rs:71:1
   |
71 | impl UnwindSafe for Condvar {}
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

@Noratrieb
Copy link
Member

Noratrieb commented Feb 27, 2024

You cannot use unstable on impls traits, it needs to be stable.

@ecton
Copy link
Contributor Author

ecton commented Feb 27, 2024

I understand that. What details do I put in the #[stable] attribute without a tracking issue? It seems like the only allowed format require linking to an issue and a name?

@Noratrieb
Copy link
Member

Stable only requires a name and version (which I'd just copy from Mutex and RwLock)

@ecton
Copy link
Contributor Author

ecton commented Feb 28, 2024

Last question: Wouldn't that cause the documentation to say that Condvar implemented the traits since a specific Rust older version? If so, wouldn't it be a concern that the docs would be misleading given that Linux is one of the only platforms it currently is unwind safe on?

@Noratrieb
Copy link
Member

🤷 I don't think it really matters, I would call it a bug before and this is fixing the bug of it always being supposed to inpelem the traits

@ecton ecton closed this as completed Feb 28, 2024
jhpratt added a commit to jhpratt/rust that referenced this issue Feb 29, 2024
Implement unwind safety for Condvar on all platforms

Closes rust-lang#118009

This commit adds unwind safety consistency to Condvar. Previously, only select platforms implemented unwind safety through auto traits. Known by this committer: On Linux, `Condvar` implemented `UnwindSafe` but on Mac and Windows, it did not. This change changes the implementation from auto to explicit.

In rust-lang#118009, it was suggested that the platform differences were a bug and that a simple PR could address this. In trying to determine the best information to put in the `#[stable]` attribute, it [was suggested](rust-lang#121690 (comment)) I copy the stability information from the previous unwind safety implementations.
jhpratt added a commit to jhpratt/rust that referenced this issue Feb 29, 2024
Implement unwind safety for Condvar on all platforms

Closes rust-lang#118009

This commit adds unwind safety consistency to Condvar. Previously, only select platforms implemented unwind safety through auto traits. Known by this committer: On Linux, `Condvar` implemented `UnwindSafe` but on Mac and Windows, it did not. This change changes the implementation from auto to explicit.

In rust-lang#118009, it was suggested that the platform differences were a bug and that a simple PR could address this. In trying to determine the best information to put in the `#[stable]` attribute, it [was suggested](rust-lang#121690 (comment)) I copy the stability information from the previous unwind safety implementations.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Feb 29, 2024
Rollup merge of rust-lang#121768 - ecton:condvar-unwindsafe, r=m-ou-se

Implement unwind safety for Condvar on all platforms

Closes rust-lang#118009

This commit adds unwind safety consistency to Condvar. Previously, only select platforms implemented unwind safety through auto traits. Known by this committer: On Linux, `Condvar` implemented `UnwindSafe` but on Mac and Windows, it did not. This change changes the implementation from auto to explicit.

In rust-lang#118009, it was suggested that the platform differences were a bug and that a simple PR could address this. In trying to determine the best information to put in the `#[stable]` attribute, it [was suggested](rust-lang#121690 (comment)) I copy the stability information from the previous unwind safety implementations.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants