Inherit `#[stable(..)]` annotations in enum variants and fields from its item #71481
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
|
CC @rust-lang/compiler who might be interested in this. |
|
I still don't think this is a good idea. |
|
Items in trait impls don't currently require stability attributes. |
Does this refer to this implementation, the general idea of stability From the first diff section in https://github.com/rust-lang/rust/pull/71481/files#diff-6bfe08b41853465a10867dc22a4a548c it seems to me that we originally intended this new behavior to be the correct one. It's also making me realize that after landing this when we update the used beta in this repo we'll also need to in the same commit update the current usages, as having two different nested
The mechanism used for |
This comment has been hidden.
This comment has been hidden.
| #![feature(staged_api)] | ||
| #![stable(feature = "test", since = "0")] | ||
|
|
||
| #[stable(feature = "test", since = "0")] | ||
| pub struct Reverse<T>(pub T); //~ ERROR field has missing stability attribute | ||
| pub struct Reverse<T>(pub T); |
nagisa
Jun 6, 2020
Contributor
I feel like this is potentially dangerous change that also limits our options in the future.
I can see an use-case in adding an unstable new field to a struct and not impacting any stable uses of the struct.
Similarly for #[non_exhaustive] enums (the only kind of enum to which it is valid to add a variant), though perhaps significantly more debatable depending on the specific case.
I feel like this is potentially dangerous change that also limits our options in the future.
I can see an use-case in adding an unstable new field to a struct and not impacting any stable uses of the struct.
Similarly for #[non_exhaustive] enums (the only kind of enum to which it is valid to add a variant), though perhaps significantly more debatable depending on the specific case.
estebank
Jun 11, 2020
Author
Contributor
I can see an use-case in adding an unstable new field to a struct and not impacting any stable uses of the struct.
I'm not sure I follow. This PR makes the linked code semantically the same as the current
#[stable(feature = "test", since = "0")]
pub struct Reverse<T>(#[stable(feature = "test", since = "0")] pub T);
but you can still add unstable (and stable with different feature name) annotations to individual fields as you add to them. You currently get a compile error with the presented code. I don't see how this change limits us?
I can see an use-case in adding an unstable new field to a struct and not impacting any stable uses of the struct.
I'm not sure I follow. This PR makes the linked code semantically the same as the current
#[stable(feature = "test", since = "0")]
pub struct Reverse<T>(#[stable(feature = "test", since = "0")] pub T);but you can still add unstable (and stable with different feature name) annotations to individual fields as you add to them. You currently get a compile error with the presented code. I don't see how this change limits us?
nikomatsakis
Jun 12, 2020
Contributor
I guess the point is more that we might accidentally stabilize struct fields without intending to?
I guess the point is more that we might accidentally stabilize struct fields without intending to?
nagisa
Jun 12, 2020
Contributor
Yeah, the reason this comment ended up being here is because I’m expressing my observation based on the removed error message, not because the struct is in any way interesting.
@nikomatsakis summarized my point well.
Yeah, the reason this comment ended up being here is because I’m expressing my observation based on the removed error message, not because the struct is in any way interesting.
@nikomatsakis summarized my point well.
|
@matthewjasper any updates on this? |
|
I'm nominating to discuss in a triage meeting and decide next steps here. |
|
Removed |
|
This was discussed in today's weekly meeting. Removing nomination. |
…sakis Inherit `#[stable(..)]` annotations in enum variants and fields from its item Lint changes for rust-lang#65515. The stdlib will have to be updated once this lands in beta and that version is promoted in master.
|
|
|
@bors retry |
…atsakis Inherit `#[stable(..)]` annotations in enum variants and fields from its item Lint changes for rust-lang#65515. The stdlib will have to be updated once this lands in beta and that version is promoted in master.
Rollup of 11 pull requests Successful merges: - rust-lang#71481 (Inherit `#[stable(..)]` annotations in enum variants and fields from its item) - rust-lang#76570 (Implement RFC 2945: "C-unwind" ABI ) - rust-lang#80527 (Make rustdoc lints a tool lint instead of built-in) - rust-lang#80723 (Implement NOOP_METHOD_CALL lint) - rust-lang#80763 (resolve: Reduce scope of `pub_use_of_private_extern_crate` deprecation lint) - rust-lang#81136 (Improved IO Bytes Size Hint) - rust-lang#82304 (Add `-Z unpretty` flags for the AST) - rust-lang#82310 (Load rustdoc's JS search index on-demand.) - rust-lang#82315 (Improve page load performance in rustdoc) - rust-lang#82411 (Fixes to ExitStatus and its docs) - rust-lang#82564 (Revert `Vec::spare_capacity_mut` impl to prevent pointers invalidation) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…sakis Inherit `#[stable(..)]` annotations in enum variants and fields from its item Lint changes for rust-lang#65515. The stdlib will have to be updated once this lands in beta and that version is promoted in master.
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
|
|
Unrelated CI failure, @bors retry |
…atsakis Inherit `#[stable(..)]` annotations in enum variants and fields from its item Lint changes for rust-lang#65515. The stdlib will have to be updated once this lands in beta and that version is promoted in master.
|
|
Lint changes for #65515. The stdlib will have to be updated once this lands in beta and that version is promoted in master.