Don't require `extern crate`

[mark-i-m]

Breaking out from #53128

Currently, extern crate is still required for sysroot crates, like test, proc_macro, core or std. One needs to extern crate them for use in no_std crates unless they are implicitly imported (like std is without #![no_std], or core with it).

• proc_macro today is automatically imported by Cargo for proc-macro declared crates
• alloc and std need extern for no_std (or std crates)
• core is automatically extern'd in for all crates

This is the tracking issue for making them not require extern crate.

[cramertj]

Requiring extern crate std; in #![no_std] crates is an intentional restriction. Otherwise, it would be easy to accidentally introduce a dependency on std. If this issue is meant to refer to the ability to specify that std should be available based on a cargo feature, then this is identical to the issue about passing --extern <cratename> (w/ no =<path>) from cargo.

[ehuss]

then this is identical to the issue about passing --extern <cratename>

Is there a tracking issue for this? It seems like there is some design work that needs to be done, but it's not clear who is responsible (cargo, lang, or compiler).

[mark-i-m]

@cramertj Are you saying this is more blocked on some sort of std-aware cargo? Also, I get that concern for std, but what about core? I don't think I have ever written a crate where I didn't want core around.

[cramertj]

No, std-aware cargo is completely unrelated. This is about exposing the existing, but unstable, --extern <cratename> flag from cargo. #53166 explains the why/how, #53130 (comment) is the "what", and #54116 is the implementation of the flag in rustc. What's wanted is the ability to make cargo pass --extern std iff an std feature is enabled. That is the cargo issue.

[dekellum]

Also please include tracking here for removing the need for extern crate test in 2018 edition, sysroot libtest benchmarks as was originally brought up in #55133, also closed without the last bit of cargo support. I would guess (without full understanding) that cargo bench and cargo build --benches, etc. needs to be updated to pass the --extern test?

[cramertj]

@dekellum Indeed-- same issue.

[Nemo157]

Also, I get that concern for std, but what about core?

You only need to extern crate core; when you're using no_core, which makes as much sense as needing extern crate std; for no_std.

Automatically injecting proc_macro (or meta or whatever it's going to be called) for crate-type = "proc-macro" is I think one of the more important variations of this, since that's most likely to affect stable users.

EDIT: Actually, rechecking #54116 it appears that meta is already injected, it just needs to be added as a real crate in the sysroot to get that functionality working.

[mark-i-m]

For whatever reason, I have needed to do extern crate core to get cross-compiled crates working. Also, there is liballoc and libtest.

[petrochenkov]

extern crate core to get cross-compiled crates working

Could you give a reproduction?
As @Nemo157 said above, core is always in extern prelude unless no_core is specified.
The only reason to use extern crate core that I can think of is this ICE - #56935.

[petrochenkov]

The issue should probably use proc_macro or alloc as an example rather than std/core.

[Nemo157]

Also, there is liballoc and libtest.

These are both unstable crates so IMO lower priority than meta or std. However, as @cramertj notes it should be possible to handle them via the same mechanism that will allow std to be injected from Cargo.toml (sysroot-aware Cargo, maybe? EDIT: nope, @petrochenkov shot that down pretty quickly).

[petrochenkov]

Also, this is not only about sysroot, but about any crates in library search directories.
(Non-sysroot search directories are used, for example, by our test suite. I'm sure there are other scenarios as well.)