You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
core::panic::PanicInfo has a set_payload method that is semi-private through #[doc(hidden)], but a pub fn so that libstd can call its definition in libcore.
error[E0658]: use of unstable library feature 'panic_internals': internal details of the implementation of the `panic!` and related macros
I’m reassure to see that it is in fact unstable, but I don’t understand why or how it got the feature gate panic_internals. I know that a stability attribute can be inherited from the parent item, but the nearest use of panic_internals is in the feature gate of the internal_constructor method which is a sibling item in the same impl block. The parent (the impl block) does not have any stability attribute. The grand-parent (the module) is unstable with the feature gate core_panic_info.
Do we have docs for the precise rules for "inherited" stability? Should we change those rules to make a stability attribute mandatory in cases like this?
@alexcrichton, do you know who would know about this? Neither the author or reviewer of #8921 is involved anymore.
The text was updated successfully, but these errors were encountered:
#![unstable(feature = "panic_internals", ... is not applied to internal_constructor, it's an inner attribute applied to impl<'a> PanicInfo<'a> in a very confusing way. :)
So, everything is good and "unstability" is still inherited from parents and not siblings.
core::panic::PanicInfo
has aset_payload
method that is semi-private through#[doc(hidden)]
, but apub fn
so that libstd can call its definition in libcore.However, it’s missing a stability attribute:
rust/src/libcore/panic.rs
Lines 60 to 64 in ab21557
Wondering if we’d accidentally stabilized it, I tried:
I’m reassure to see that it is in fact unstable, but I don’t understand why or how it got the feature gate
panic_internals
. I know that a stability attribute can be inherited from the parent item, but the nearest use ofpanic_internals
is in the feature gate of theinternal_constructor
method which is a sibling item in the sameimpl
block. The parent (theimpl
block) does not have any stability attribute. The grand-parent (the module) is unstable with the feature gatecore_panic_info
.Do we have docs for the precise rules for "inherited" stability? Should we change those rules to make a stability attribute mandatory in cases like this?
@alexcrichton, do you know who would know about this? Neither the author or reviewer of #8921 is involved anymore.
The text was updated successfully, but these errors were encountered: