Make LocalWaker::new a const fn #53456
Conversation
rust-highfive
added
the
S-waiting-on-review
| @@ -119,7 +119,7 @@ impl LocalWaker { | |||
| /// For this function to be used safely, it must be sound to call `inner.wake_local()` | |||
| /// on the current thread. | |||
| #[inline] | |||
| pub unsafe fn new(inner: NonNull<dyn UnsafeWake>) -> Self { | |||
| pub const unsafe fn new(inner: NonNull<dyn UnsafeWake>) -> Self { | |||
There was a problem hiding this comment.
Please add the rustc_const_unstable attribute and a test enabling the feature and using it.
There was a problem hiding this comment.
See #47562 for an example.
There was a problem hiding this comment.
Yep, I managed to get an example going. Unfortunately writing that example made me realise that this isn't usable for what I want anyway since it's !Send + !Sync so can't go in a static, as I don't know of any other usecases for this to be const I'm gonna close this and try to find an alternative.
One thing I noticed while adding the example, rustc_const_unstable requires a stable/unstable directly on the item being annotated, LocalWaker is in an unstable module so doesn't have a direct annotation, is there some reason the attribute needs to be directly on the item instead of inheriting from its parent scope?
There was a problem hiding this comment.
Is there some reason the attribute needs to be directly on the item instead of inheriting from its parent scope?
Does implementation lazyness count as a reason?
Most newly added const fns already had a stability attribute, so it was less hazzle to add an attribute to those that didn't have it than to correctly implement the attribute
There was a problem hiding this comment.
Implementation lazyness is the best reason.
There was a problem hiding this comment.
<Joke about Haskell has been elided due to laziness>
This is mostly not that useful, except for
futures-testwhere we want to have statics available for the more trivial test wakers for better ergonomics.r? @cramertj