Closed
Description
Example crate(s): https://github.com/jrobsonchase/cloud_to_butt
It appears that rust stable 1.30 allows the use of absolute paths to items from other crates without the extern crate
declaration. This works in code, but not in use
statements.
I originally thought it was just a proc-macro crate problem since that's where I noticed it first, but it shows up in both. See https://github.com/jrobsonchase/cloud_to_butt/blob/master/src/lib.rs#L28 and https://github.com/jrobsonchase/cloud_to_butt/blob/master/cloud/src/main.rs#L10. Both contain full paths to syn/proc_macro2 items that shouldn't be available since there's been no extern crate
for either.
my rustc version:
rustc 1.30.0 (da5f414c2 2018-10-24)
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
[-]Rust stable 1.30 proc-macro crates allow use of extern crates without declaration[/-][+]Rust stable 1.30 allows use of extern crates without declaration[/+]petrochenkov commentedon Oct 29, 2018
This is by design, crate names passed with
--extern
are put into prelude and available from the whole crate without imports for compatibility with 2018 edition, but also for convenience.This is what the "Module system improvements" section in the announce blog post attempted to convey.
jrobsonchase commentedon Oct 29, 2018
petrochenkov commentedon Oct 29, 2018
@jrobsonchase
Yes,
use
on 2015 edition still uses paths relative to the crate root, so foruse my_crate::foo;
to workmy_crate
must be somehow defined in the crate root, usually viaextern crate my_crate;
.On 2018 edition imports will be able to work without
extern crate my_crate;
items too, makingextern crate
nearly obsolete.So, on 2015, I think, there's now a choice between two guidelines on how to use
extern crate
items:extern crate
items only if necessary for imports, andextern crate
for all used crates for consistency (or to support older versions ofrustc
).jrobsonchase commentedon Oct 29, 2018
petrochenkov commentedon Oct 29, 2018
Yes, "full path" -> "relative path starting with a crate name" to be precise.
Correct.
In this case you may want to follow the guideline
2.
and useextern crate
for everything.petrochenkov commentedon Oct 29, 2018
FWIW, unresolved imports still explicitly recommend adding an
extern crate
item:so it's clear what to do when a person unfamiliar with the rules encounters this error.
jrobsonchase commentedon Oct 29, 2018
petrochenkov commentedon Oct 29, 2018
Because
some_crate::do_something()
anduse some_crate::do_something
are resolved very differently (relative paths vs absolute paths).(That was always a source of confusion, and the whole 2018 module system overhaul started from the desire to remove this distinction.)
(By the way, other prelude names behave very similarly, i.e. you can write
Vec::new()
, but notuse Vec;
,println!(...)
, but notuse println;
).petrochenkov commentedon Dec 18, 2018
My plan so far is to implement fallback from crate-relative names (
crate::foo
) to extern crates (extern::foo
) in imports (use foo::bar
) on 2015 edition and make crater experiment.If everything is good, we'll be able to support
use my_crate::bar
imports on Rust 2015 as well as on Rust 2018.Auto merge of #57745 - petrochenkov:uni2015, r=<try>
petrochenkov commentedon Jan 18, 2019
#57745 is implementation of that plan.
petrochenkov commentedon Mar 21, 2019
There was not enough interest in addressing this issue in #57745, closing.