Skip to content
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

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

Closed
japaric opened this issue Sep 6, 2018 · 10 comments · Fixed by #54116
Closed

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

japaric opened this issue Sep 6, 2018 · 10 comments · Fixed by #54116
Assignees
Labels
C-bug Category: This is a bug. P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@japaric
Copy link
Member

japaric commented Sep 6, 2018

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 Centril added P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Sep 7, 2018
@Centril
Copy link
Contributor

Centril commented Sep 7, 2018

Marking as P-high due to edition urgency.

@alexcrichton
Copy link
Member

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

@eddyb
Copy link
Member

eddyb commented Sep 10, 2018

@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
Copy link
Member

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
Copy link
Contributor

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

@nikomatsakis
Copy link
Contributor

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

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

@pnkfelix
Copy link
Member

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

@nikomatsakis
Copy link
Contributor

Another question:

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

@nikomatsakis
Copy link
Contributor

(If you invoke rustc manually, or maybe by cajoling cargo sufficiently)

@eddyb
Copy link
Member

eddyb commented Sep 13, 2018

@nikomatsakis The only way you can access the sysroot crate without knowing its path is the new --extern alloc (without a path), that's being added in #54116, which is unstable.

We can't check stability when we load the crate, because that happens before the query engine is set up, and it's a pretty messy right now to get any useful information across.

What we could do is try to get a stability check into #54145.

bors added a commit that referenced this issue Sep 15, 2018
rustc_resolve: allow only core, std, meta and --extern in Rust 2018 paths.

As per #53166 (comment):
* Rust 2018 imports can no longer refer to crates not in "extern prelude"
  * `::foo` won't load a crate named `foo` unless `foo` is in the "extern prelude"
  * `extern crate foo;`, however, remains unchanged (can load arbitrary crates)
* `--extern crate_name` is added (note the lack of `=path`) as an unstable option
  * adds `crate_name` to the "extern prelude" (see above)
  * crate is searched in sysroot & library paths, just like `extern crate crate_name`.
  * `Cargo` support will be added later
* `core`, `std` and ~~`proc_macro`~~ `meta` are *always* available in the extern prelude
  * warning for interaction with `no_std` / `no_core` will be added later
  * **EDIT**: `proc_macro` was replaced by `meta`, see #53166 (comment)
    * note that there is no crate named `meta` being added, so `use meta::...;` will fail, we're only whitelisting it so we can start producing `uniform_paths` compatibility errors

Fixes #54006 (as the example now requires `--extern alloc`, which is unstable).
Fixes #54253 (hit during fixing RLS).

r? @petrochenkov cc @aturon @alexcrichton @Centril @joshtriplett
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants