Skip to content

Stability checker doesn't recurse down reexports properly #21905

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

Open
Manishearth opened this issue Feb 3, 2015 · 4 comments
Open

Stability checker doesn't recurse down reexports properly #21905

Manishearth opened this issue Feb 3, 2015 · 4 comments
Labels
A-stability Area: `#[stable]`, `#[unstable]` etc. C-bug Category: This is a bug. F-staged_api `#![feature(staged_api)]` T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@Manishearth
Copy link
Member

Manishearth commented Feb 3, 2015

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 uses.

cc @brson

@brson brson self-assigned this Feb 3, 2015
@brson brson added the A-libs label Feb 3, 2015
@steveklabnik
Copy link
Member

Traige: staged_api is now only available to the compiler, so I was unable to come up with a quick test case.

@petrochenkov
Copy link
Contributor

Still an issue.
(Also, staged_api is still available to everyone on unstable, it just uses misleading error message to hide the truth.)

@steveklabnik
Copy link
Member

Ahhh I thought I was using unstable, I guess I wasn't.

On Mar 4, 2016, 12:03 -0500, Vadim [email protected], wrote:

Still an issue.
(Also,staged_apiis still available to everyone on unstable, it just uses misleading error message to hide the truth.)


Reply to this email directly orview it on GitHub(#21905 (comment)).

@brson brson removed their assignment Jul 11, 2016
@petrochenkov petrochenkov added the A-stability Area: `#[stable]`, `#[unstable]` etc. label Feb 19, 2017
@steveklabnik steveklabnik added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed A-libs labels Mar 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 22, 2017
@steveklabnik
Copy link
Member

Triage: not aware of any changes at all here. There's not a ton of pressure to fix this.

@fmease fmease added the F-staged_api `#![feature(staged_api)]` label Dec 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-stability Area: `#[stable]`, `#[unstable]` etc. C-bug Category: This is a bug. F-staged_api `#![feature(staged_api)]` T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants