unstable `alloc` crate can be used without feature gates on the 2018 edition

[japaric]

STR

This compiles when edition = "2018"

// crate-type: lib
#![no_std]

use alloc::vec;

fn foo() {
    let mut xs = vec![];
    xs.push(0);
}

This doesn't compile when edition = "2015" because it needs a feature gate.

// crate-type: lib
#![no_std]

extern crate alloc; //~ ERROR use of unstable library feature `alloc`

use alloc::vec;

fn foo() {
    let mut xs = vec![];
    xs.push(0);
}

Meta

$ rustc -V
rustc 1.30.0-nightly (6e0f1cc15 2018-09-05)

[Centril]

Marking as P-high due to edition urgency.

[alexcrichton]

This sounds the same as #52489, curious! cc @eddyb

[eddyb]

@alexcrichton Uhhhh this is because we can't stability-check intermediary path components.
alloc::vec is stable, it's just alloc that's not - this is the same as std::intrinsics::transmute.

cc @petrochenkov This seems much worse than usual.

OTOH, I do have a branch where you have to use extern crate alloc; or pass --extern alloc to the compiler, that I'm working on right now. Would that alleviate the issue for now?

[alexcrichton]

Ah yes, indeed!

The "intermediary path components stability doesn't work" has never been high priority because the root crate always had to be listed as extern crate foo. I would agree that if you don't have to write extern crate foo this is definitely much higher priority now

[nikomatsakis]

Can't we check the stability when we do the lazy path resolution?

[nikomatsakis]

Sorry, that's not very clear. What I meant is:

Can we do the stability checking when we first load the crate?

[pnkfelix]

Visited for triage. Assigning to @eddyb, who sounds like they are on the case.

[nikomatsakis]

Another question:

Can you specify --extern to access alloc without a feature gate?