-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-stabilityArea: `#[stable]`, `#[unstable]` etc.Area: `#[stable]`, `#[unstable]` etc.C-bugCategory: This is a bug.Category: This is a bug.F-staged_api`#![feature(staged_api)]``#![feature(staged_api)]`T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Description
stability.rs:
#![crate_type="lib"]
#![feature(staged_api)]
#![staged_api]
#![stable(feature = "stability", since = "1.0.0")]
mod foo {
#[derive(Copy)]
pub struct Bar;
}
#[unstable(feature="foobar")]
pub mod foobar {
pub use super::foo::*;
}
test.rs:
extern crate stability;
use stability::foobar::Bar;
fn main(){
let x = Bar; //~ ERROR use of unmarked library feature
}
#[unstable]
is inherited through mods (only #[stable]
isn't inherited). However, in this particular case, the inheritance doesn't cross the reexport.
A more concrete example is the hash_state
module. Chris fixed the stability of its items in this PR, however the module itself was private and reexported as an #[unstable]
module before the PR. Yet, usage of items within the hash_state
module were broken before the PR.
This seems wrong, #[unstable]
(and the others, except #[stable]
) should be inherited down pub use
s.
cc @brson
Metadata
Metadata
Assignees
Labels
A-stabilityArea: `#[stable]`, `#[unstable]` etc.Area: `#[stable]`, `#[unstable]` etc.C-bugCategory: This is a bug.Category: This is a bug.F-staged_api`#![feature(staged_api)]``#![feature(staged_api)]`T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.