unintended provocation of thread_local_internals feature

[BurntSushi]

I have no idea what's causing this, but on the current nightly, this fails:

use std::thread::scoped;
fn main() { let _ = scoped(move || ()); }

with "use of unstable library feature 'thread_local_internals'." Enabling the feature works, but this should be a stable function. Interestingly, tweaking the use works:

use std::thread;
fn main() { let _ = thread::scoped(move || ()); }

I wonder if it's because there is a (private) sub-module called scoped which has a module-wide unstable marker.

Version info:

[andrew@Liger scoped] rustc --version
rustc 1.0.0-nightly (93f7fe32d 2015-04-10) (built 2015-04-11)

[rprichard]

I wonder if it's because there is a (private) sub-module called scoped which has a module-wide unstable marker.

This change was introduced just recently: f651bea.

I reproduced the problem without using anything thread-related:

mycrate.rs:

#![feature(staged_api)]
#![crate_type = "lib"]
#![staged_api]
#![stable(feature = "mycrate", since = "1.0.0")]

#[unstable(feature = "mycrate_internals")]
mod bar {}
#[stable(feature = "mycrate", since = "1.0.0")]
pub fn bar() {}

main.rs:

extern crate mycrate;
use mycrate::bar;
fn main() {}

Commands:

rustc mycrate.rs
rustc main.rs -L.

Output:

main.rs:2:5: 2:17 error: use of unstable library feature 'mycrate_internals'
main.rs:2 use mycrate::bar;
              ^~~~~~~~~~~~
main.rs:2:17: 2:17 help: add #![feature(mycrate_internals)] to the crate attributes to enable
main.rs:2:5: 2:17 warning: unused import, #[warn(unused_imports)] on by default
main.rs:2 use mycrate::bar;
              ^~~~~~~~~~~~

• If I remove the unstable attribute from the mycrate::bar module, the code gives me the use of unmarked library feature error.
• I mark mycrate::bar as stable, then the code compiles.
• If I instead remove the mycrate::bar function, I get the module bar is private error.

cc @alexcrichton

[steveklabnik]

With #24362 merged, is this fixed?

[alexcrichton]

The exact issue at hand has been resolved, but the underlying issue remains. Specifically a module and free-function of the same name but different stability level will cause problems.

[shadowmint]

Also hit by this; still affecting the nightly for osx right now, but hopefully the next build will include the fix.

[brson]

Stability is an internal detail. This is unlikely to impact out-of-tree code.