-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for stability attributes: #[deprecated], #[experimental], etc. #8921
Conversation
There are 6 new compiler recognised attributes: deprecated, experimental, unstable, stable, frozen, locked (these levels are taken directly from Node's "stability index"[1]). These indicate the stability of the item to which they are attached; e.g. `#[deprecated] fn foo() { .. }` says that `foo` is deprecated. This comes with 3 lints for the first 3 levels (with matching names) that will detect the use of items marked with them (the `unstable` lint includes items with no stability attribute). The attributes can be given a short text note that will be displayed by the lint. An example: #[warn(unstable)]; // `allow` by default #[deprecated="use `bar`"] fn foo() { } #[stable] fn bar() { } fn baz() { } fn main() { foo(); // "warning: use of deprecated item: use `bar`" bar(); // all fine baz(); // "warning: use of unmarked item" } The lints currently only check the "edges" of the AST: i.e. functions, methods[2], structs and enum variants. Any stability attributes on modules, enums, traits and impls are not checked. [1]: http://nodejs.org/api/documentation.html [2]: the method check is currently incorrect and doesn't work.
There's one major problem: I can't get the attributes attached to a method from the point that it is called. i.e. struct Foo;
impl Foo {
#[deprecated]
fn method(&self) {}
}
fn main() {
Foo.method(); // how to I retrieve the `deprecated` attribute above?
} The information isn't in the |
1000 kudos! |
Looks like method_map is the way to get that info, so I guess it needs to be given to the lint passes. |
I think this is a crucial feature for stabilizing the language. Some considerations
|
I suspect the term 'unmarked' is a bit unclear here. Maybe also call it unstable but with some additional note that the item isn't annotated. |
Significant progress on #6875, enough that I'll open new bugs and turn that into a metabug when this lands. Description & example in the commit message.
I was thinking that #[stable]
pub mod vec {
pub fn from_elem() { }
#[unstable] pub fn from_fn() { }
} would mean that
It currently marks
They get marked too; it's not entirely obvious to me how to fix this.
Agreed. |
If you inherit stability like that, we are going to accidentally stabilize a lot of functions without the necessary discussion. |
Hm; it's not necessary to inherit: the only way to actually access those functions will go though the module: i.e. if a crate has a stability annotation then the |
Add `Operators` lint pass changelog: None
Significant progress on #6875, enough that I'll open new bugs and turn that into a metabug when this lands.
Description & example in the commit message.