rust
rust copied to clipboard
rust-lang
Implement `#[rustc_default_body_unstable]`
This PR implements a new stability attribute — #[rustc_default_body_unstable].
#[rustc_default_body_unstable] controls the stability of default bodies in traits.
For example:
pub trait Trait {
#[rustc_default_body_unstable(feature = "feat", isssue = "none")]
fn item() {}
}
In order to implement Trait user needs to either
- implement
item(even though it has a default implementation) - enable
#![feature(feat)]
This is useful in conjunction with #[rustc_must_implement_one_of], we may want to relax requirements for a trait, for example allowing implementing either of PartialEq::{eq, ne}, but do so in a safe way — making implementation of only PartialEq::ne unstable.
r? @Aaron1011
cc @nrc (iirc you were interested in this wrt read_buf), @danielhenrymantilla (you were interested in the related #[rustc_must_implement_one_of])
P.S. This is my first time working with stability attributes, so I'm not sure if I did everything right 😅
The job mingw-check failed! Check out the build log: (web) (plain)
Click to see the possible cause of the failure (guessed by this bot)
Checking rustc_builtin_macros v0.0.0 (/checkout/compiler/rustc_builtin_macros)
error[E0425]: cannot find value `CRATE_DEF_INDEX` in this scope
--> compiler/rustc_middle/src/middle/stability.rs:447:50
|
447 | self.lookup_stability(DefId { index: CRATE_DEF_INDEX, ..def_id }).is_some();
|
help: consider importing one of these items
|
4 | use rustc_hir::def_id::CRATE_DEF_INDEX;
:umbrella: The latest upstream changes (presumably #97177) made this pull request unmergeable. Please resolve the merge conflicts.
:umbrella: The latest upstream changes (presumably #95956) made this pull request unmergeable. Please resolve the merge conflicts.
Sorry for the extreme delay - I had forgotten that this was assigned to me.
This looks good to me overall - do we need lang-team signoff before adding this?
do we need lang-team signoff before adding this?
I don't know, maybe 😄
r=me after confirmation from the libs teem that this is okay (or after an FCP if needed)
@Aaron1011 why libs team approval is needed? This PR doesn't change any library APIs after all.
Quoting @scottmcm on zulip:
Looks like it doesn't change anything in library at all? If this is just a compiler feature that could be used in library later, then I don't think it's blocked on libs review.