Stability inherited from *sibling* item?

[SimonSapin]

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.

However, it’s missing a stability attribute:

rust/src/libcore/panic.rs

Lines 60 to 64 in ab21557

	#[doc(hidden)]
	#[inline]
	pub fn set_payload(&mut self, info: &'a (dyn Any + Send)) {
	self.payload = info;
	}

Wondering if we’d accidentally stabilized it, I tried:

fn foo(p: &mut std::panic::PanicInfo) {
    p.set_payload(&());
}

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.

[petrochenkov]

#![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.

[SimonSapin]

Ouch, good catch! And I think this one is my fault…

So, everything is good

Indeed.