Detect stability attributes on modules and crates #8962
Labels
A-attributes
Area: Attributes (`#[…]`, `#![…]`)
A-lint
Area: Lints (warnings about flaws in source code) such as unused_mut.
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
Comments
This was referenced Sep 3, 2013
|
I'll work on this one |
aturon
added a commit
to aturon/rust
that referenced
this issue
Jun 19, 2014
This commit makes several changes to the stability index infrastructure: * Stability levels are now inherited lexically, i.e., each item's stability level becomes the default for any nested items. * The computed stability level for an item is stored as part of the metadata. When using an item from an external crate, this data is looked up and cached. * The stability lint works from the computed stability level, rather than manual stability attribute annotations. However, the lint still checks only a limited set of item uses (e.g., it does not check every component of a path on import). This will be addressed in a later PR, as part of issue rust-lang#8962. * The stability lint only applies to items originating from external crates, since the stability index is intended as a promise to downstream crates. * The "experimental" lint is now _allow_ by default. This is because almost all existing crates have been marked "experimental", pending library stabilization. With inheritance in place, this would generate a massive explosion of warnings for every Rust program. The lint should be changed back to deny-by-default after library stabilization is complete. * The "deprecated" lint still warns by default. The net result: we can begin tracking stability index for the standard libraries as we stabilize, without impacting most clients. Closes rust-lang#13540.
bors
added a commit
that referenced
this issue
Jun 21, 2014
This commit makes several changes to the stability index infrastructure: * Stability levels are now inherited lexically, i.e., each item's stability level becomes the default for any nested items. * The computed stability level for an item is stored as part of the metadata. When using an item from an external crate, this data is looked up and cached. * The stability lint works from the computed stability level, rather than manual stability attribute annotations. However, the lint still checks only a limited set of item uses (e.g., it does not check every component of a path on import). This will be addressed in a later PR, as part of issue #8962. * The stability lint only applies to items originating from external crates, since the stability index is intended as a promise to downstream crates. * The "experimental" lint is now _allow_ by default. This is because almost all existing crates have been marked "experimental", pending library stabilization. With inheritance in place, this would generate a massive explosion of warnings for every Rust program. The lint should be changed back to deny-by-default after library stabilization is complete. * The "deprecated" lint still warns by default. The net result: we can begin tracking stability index for the standard libraries as we stabilize, without impacting most clients. Closes #13540.
nrc
pushed a commit
to nrc/rust
that referenced
this issue
Aug 22, 2014
This commit makes several changes to the stability index infrastructure: * Stability levels are now inherited lexically, i.e., each item's stability level becomes the default for any nested items. * The computed stability level for an item is stored as part of the metadata. When using an item from an external crate, this data is looked up and cached. * The stability lint works from the computed stability level, rather than manual stability attribute annotations. However, the lint still checks only a limited set of item uses (e.g., it does not check every component of a path on import). This will be addressed in a later PR, as part of issue rust-lang#8962. * The stability lint only applies to items originating from external crates, since the stability index is intended as a promise to downstream crates. * The "experimental" lint is now _allow_ by default. This is because almost all existing crates have been marked "experimental", pending library stabilization. With inheritance in place, this would generate a massive explosion of warnings for every Rust program. The lint should be changed back to deny-by-default after library stabilization is complete. * The "deprecated" lint still warns by default. The net result: we can begin tracking stability index for the standard libraries as we stabilize, without impacting most clients. Closes rust-lang#13540.
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Feb 11, 2015
There are a number of holes that the stability lint did not previously cover,
including:
* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)
These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:
* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local::imp::Key` type is now stable (it was already supposed to
be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
make bounds with these traits stable. Note that manual implementations of
these traits are still gated by default, this stability only allows bounds
such as `F: FnOnce()`.
Additionally, the compiler now has special logic to ignore its own generated
`__test` module for the `--test` harness in terms of stability.
Closes rust-lang#8962
Closes rust-lang#16360
Closes rust-lang#20327
[breaking-change]
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Feb 11, 2015
There are a number of holes that the stability lint did not previously cover,
including:
* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)
These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:
* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local::imp::Key` type is now stable (it was already supposed to
be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
make bounds with these traits stable. Note that manual implementations of
these traits are still gated by default, this stability only allows bounds
such as `F: FnOnce()`.
Closes rust-lang#8962
Closes rust-lang#16360
Closes rust-lang#20327
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Jul 28, 2022
Fix `mismatching_type_param_order` false positive changelog: Don't lint `mismatching_type_param_order` on complicated generic params fixes rust-lang#8962
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It seems unlikely that this should flag crates and modules without annotations, but I'm not really sure.
(Part of #6875, continuation of #8921.)
The text was updated successfully, but these errors were encountered: