Rust stable 1.30 allows use of extern crates without declaration

[jrobsonchase]

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)

[petrochenkov]

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]

Ok, but is it by design that you can use absolute paths without `extern crate`, but if you want to use `use`, the `extern crate` is still required?

…

On Mon, Oct 29, 2018, 12:06 Vadim Petrochenkov ***@***.***> wrote: 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 <https://blog.rust-lang.org/2018/10/25/Rust-1.30.0.html> attempted to convey. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#55478 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABe0rW5o3RDKlZM2JFHfIpVj0LfClLkGks5upyeLgaJpZM4X_eFP> .

[petrochenkov]

@jrobsonchase
Yes, use on 2015 edition still uses paths relative to the crate root, so for use my_crate::foo; to work my_crate must be somehow defined in the crate root, usually via extern crate my_crate;.
On 2018 edition imports will be able to work without extern crate my_crate; items too, making extern crate nearly obsolete.

So, on 2015, I think, there's now a choice between two guidelines on how to use extern crate items:

1. Add extern crate items only if necessary for imports, and
2. Add extern crate for all used crates for consistency (or to support older versions of rustc).

[jrobsonchase]

So just to clarify: it's intended behavior to be able to use things from dependency crates without `extern crate` as long as you use the full path, but as soon as you want to refactor and bring things into local scope with `use`, *then* you need `extern crate` as well? If so, I find that to be an extremely unintuitive intermediate step between 2015's "you must always have `extern crate` declarations" and 2018's "you almost never need `extern crate`."

…

On Mon, Oct 29, 2018, 14:35 Vadim Petrochenkov ***@***.***> wrote: @jrobsonchase <https://github.com/jrobsonchase> Yes, use on 2015 edition still uses paths relative to the crate root, so for use my_crate::foo; to work my_crate must be somehow defined in the crate root, usually via extern crate my_crate;. On 2018 edition imports will be able to work without extern crate my_crate; items too, making extern crate nearly obsolete. So, on 2015, I think, there's now a choice between two guidelines on how to use extern crate items: 1. Add extern crate items only if necessary for imports, and 2. Add extern crate for all used crates for consistency (or to support older versions of rustc). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55478 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABe0rf2aHKPBJl4yEm9PQyffOI2dpI4Uks5up0pXgaJpZM4X_eFP> .

[petrochenkov]

it's intended behavior to be able to use things from
dependency crates without extern crate as long as you use the full path

Yes, "full path" -> "relative path starting with a crate name" to be precise.

but as soon as you want to refactor and bring things into local scope with
use, then you need extern crate as well

Correct.

If so, I find that to be an
extremely unintuitive intermediate step between 2015's "you must always
have extern crate declarations" and 2018's "you almost never need extern crate."

In this case you may want to follow the guideline 2. and use extern crate for everything.

[petrochenkov]

FWIW, unresolved imports still explicitly recommend adding an extern crate item:

error[E0432]: unresolved import `my_crate`
 --> src/main.rs:1:5
  |
1 | use my_crate::foo;
  |     ^^^^^^^^ Maybe a missing `extern crate my_crate;`?

so it's clear what to do when a person unfamiliar with the rules encounters this error.

[jrobsonchase]

That may be so, but it's still unclear why `some_crate::do_something();` is perfectly valid and resolvable, but `use some_crate::do_something; do_something();` is not. Obviously in the first invocation, `some_crate` was resolved fine without the extern declaration, so why can the `use` not resolve it as well? To the user, it seems rather arbitrary.

…

On Mon, Oct 29, 2018, 16:34 Vadim Petrochenkov ***@***.***> wrote: FWIW, unresolved imports still explicitly recommend adding an extern crate item: error[E0432]: unresolved import `my_crate` --> src/main.rs:1:5 |1 | use my_crate::foo; | ^^^^^^^^ Maybe a missing `extern crate my_crate;`? so it's clear what to do when a person unfamiliar with the rules encounters this error. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55478 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABe0rTQw90agj4G8FYxVPmZtqr-qKZ8xks5up2ZjgaJpZM4X_eFP> .

[petrochenkov]

Because some_crate::do_something() and use 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 not use Vec;, println!(...), but not use println;).

[petrochenkov]

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.

[petrochenkov]

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.

#57745 is implementation of that plan.