remove pointless allowed_through_unstable_modules on TryFromSliceError

[RalfJung]

This got added in #132482 but the PR does not explain why. @lukas-code do you still remember? Also Cc @Noratrieb as reviewer of that PR.

If I understand the issue description correctly, all paths under which this type is exported are stable now: core::array::TryFromSliceError and std::array::TryFromSliceError. If that is the case, we shouldn't have the attribute; it's a terrible hack that should only be used when needed to maintain backward compatibility. Getting some historic information right is IMO not sufficient justification to risk accidentally exposing this type via more unstable paths today or in the future.

[rustbot]

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

The rustc-dev-guide subtree was changed. If this PR only touches the dev guide consider submitting a PR directly to rust-lang/rustc-dev-guide otherwise thank you for updating the dev guide with your changes.

cc @BoxyUwU, @jieyouxu, @Kobzol

[lukas-code]

The point of adding this atrribute was to make the "since" version on the rustdoc page show up correctly: https://doc.rust-lang.org/nightly/core/array/struct.TryFromSliceError.html

std::array::TryFromSliceError is stably exposed by that path in 1.34.0, but the module std::array is only stably exposed in 1.35.0. (This is becaue we didn't the full path stability back then.)

Usually, we want to show the stability of the "most unstable" path component in rustdoc, this is important for example for core::error::Error, which itself has a #[stable(since = "1.0.0")] attribute, but shows as "stable since 1.81.0", because that's when core::error got stabilized: https://doc.rust-lang.org/nightly/core/error/trait.Error.html

But by that logic std::array::TryFromSliceError would also show as stable since 1.35.0.

---

Getting some historic information right is IMO not sufficient justification to risk accidentally exposing this type via more unstable paths today or in the future.

This seems plausible to me, and there are probably very few crates that still use MSRV 1.34.0 and name this type dicectly, so I'm fine with removing this again.

[RalfJung]

The point of adding this atrribute was to make the "since" version on the rustdoc page show up correctly: https://doc.rust-lang.org/nightly/core/array/struct.TryFromSliceError.html

It is news to me that rustdoc actually uses the attribute when computing the information shown there, but maybe it does? Cc @notriddle

I am not sure if there is some other way to get rustdoc to show the correct information here, but whatever we do should be rustdoc-only and not affect how rustc behaves on current stable releases. But it's probably not worth worrying about this tiny mistake only affecting a single version released five years ago...

Usually, we want to show the stability of the "most unstable" path component in rustdoc, this is important for example for core::error::Error, which itself has a #[stable(since = "1.0.0")] attribute, but shows as "stable since 1.81.0", because that's when core::error got stabilized: https://doc.rust-lang.org/nightly/core/error/trait.Error.html

TBH I find that page confusing since it is not at all clear that the "Since 1.81.0" refers to the path rather than the item.

[notriddle]

It is news to me that rustdoc actually uses the attribute when computing the information shown there, but maybe it does?

I don't think the allowed_through_unstable_modules attribute is supposed to affect the version number shown there. That version number is calculated in this code:

https://github.com/rust-lang/rust/blob/master/src/librustdoc/passes/propagate_stability.rs

If the item was inlined, it'll pick the version number from the import, but allowed_through_unstable_modules off the original item. allowed_through_unstable_modules isn't specified on imports because it makes no sense there.

TBH I find that page confusing since it is not at all clear that the "Since 1.81.0" refers to the path rather than the item.

Assuming we want the number there to refer to the item, where should the stability of the path be specified? We don't want someone to copy a path into their code, with a "stable since 1.0" badge on it, only to actually try it in the 1.73 compiler and get rug-pulled when it turns out not to actually be stable. That's pretty bad for people's confidence in the docs.

The clearest, most explicit option of flat-out adding another attribute, like this?

Trait Error

Since 1.0.0 • In core since 1.81.0 • Source

It's unambiguous, but it's also not great for progressive disclosure, because that's a pretty complex concept that most people don't need to care about.