Rust: Tracking issue for no more `extern crate` for sysroot crates

[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).

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. https://github.com/rust-lang/rust/issues/53166 explains the why/how, https://github.com/rust-lang/rust/issues/53130#issuecomment-414616276 is the "what", and https://github.com/rust-lang/rust/pull/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 - https://github.com/rust-lang/rust/issues/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.)

[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.

Could you give a reproduction?

Ah, my mistake I went back and looked at the code, and it was liballoc.

[alercah]

I just ran into this in a proc macro crate. Notwithstanding the possibility that proc-macro libraries import proc_macro by default, my user instinct would be the following stanza in my Cargo.toml:

[dependencies]
proc_macro = { builtin = true }

I know it's not technically builtin, it's actually provided by the distribution. But to a user it feels like it's a builtin.

[cramertj]

@alercah This isn't only for builtin crates, but for anything that should be pulled in from library search directories (could be arbitrary crates).

[Nemo157]

What is the next required step for this, does it require an RFC, or can it be implemented as an unstable feature in Cargo without that? If the latter, should there be a separate Cargo issue opened to track actually getting some feature implemented there that will solve this?

(Somewhat related to this issue, should there be a tracking issue for what is happening around meta if that is the intended solution for proc-macros?)

[aturon]

cc @rust-lang/cargo

[SimonSapin]

As far as I understand this issue applies to the test and proc_macro crates, independently of #![no_std]. I’ve edited the issue description accordingly.

[Lokathor]

Tracking issue note: alloc just became stable (1.36) and you need to say extern crate alloc;, so it can go in the issue list now I guess.

At the same time, you _don't_ need to say extern crate core; if you're using normal rust code any more, so core can be removed from the list.

EDIT: you need to say extern crate core; for ![no_core] crates, but not for ![no_std] or "normal" crates, which should be clarified in the listing.

[ehuss]

Would people be for or against stabilizing the bare --extern flag now? My intent is to automatically issue that flag for proc_macro for proc-macro crates to avoid the need for extern crate. There hasn't been any visible progress on the transition to the meta crate, so I suspect it will be a long time for that to happen.

This doesn't immediately help for other crates, but would pave the way for future changes in cargo that might allow making these dependencies explicit.