Repository navigation
Don't require extern crate #57288
Description
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 unless they are implicitly imported (like no_std cratesstd 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.
Activity
cramertj commentedon Jan 2, 2019
Requiring
extern crate std;in#![no_std]crates is an intentional restriction. Otherwise, it would be easy to accidentally introduce a dependency onstd. If this issue is meant to refer to the ability to specify thatstdshould be available based on a cargo feature, then this is identical to the issue about passing--extern <cratename>(w/ no=<path>) fromcargo.ehuss commentedon Jan 2, 2019
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 commentedon Jan 2, 2019
@cramertj Are you saying this is more blocked on some sort of std-aware cargo? Also, I get that concern for
std, but what aboutcore? I don't think I have ever written a crate where I didn't wantcorearound.cramertj commentedon Jan 2, 2019
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 stdiff anstdfeature is enabled. That is the cargo issue.dekellum commentedon Jan 2, 2019
Also please include tracking here for removing the need for
extern crate testin 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) thatcargo benchandcargo build --benches, etc. needs to be updated to pass the--extern test?cramertj commentedon Jan 2, 2019
@dekellum Indeed-- same issue.
Nemo157 commentedon Jan 3, 2019
You only need to
extern crate core;when you're usingno_core, which makes as much sense as needingextern crate std;forno_std.Automatically injecting
proc_macro(ormetaor whatever it's going to be called) forcrate-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
metais already injected, it just needs to be added as a real crate in the sysroot to get that functionality working.mark-i-m commentedon Jan 3, 2019
For whatever reason, I have needed to do
extern crate coreto get cross-compiled crates working. Also, there is liballoc and libtest.petrochenkov commentedon Jan 3, 2019
Could you give a reproduction?
As @Nemo157 said above,
coreis always in extern prelude unlessno_coreis specified.The only reason to use
extern crate corethat I can think of is this ICE - #56935.petrochenkov commentedon Jan 3, 2019
The issue should probably use
proc_macroorallocas an example rather thanstd/core.Nemo157 commentedon Jan 3, 2019
These are both unstable crates so IMO lower priority than
metaorstd. However, as @cramertj notes it should be possible to handle them via the same mechanism that will allowstdto be injected fromCargo.toml(sysroot-aware Cargo, maybe?EDIT: nope, @petrochenkov shot that down pretty quickly).petrochenkov commentedon Jan 3, 2019
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 commentedon Jan 3, 2019
Ah, my mistake I went back and looked at the code, and it was
liballoc.6 remaining items
SimonSapin commentedon Mar 5, 2019
As far as I understand this issue applies to the
testandproc_macrocrates, independently of#![no_std]. I’ve edited the issue description accordingly.Lokathor commentedon Jul 4, 2019
Tracking issue note:
allocjust became stable (1.36) and you need to sayextern crate alloc;, so it can go in the issue list now I guess.At the same time,
you don't need to sayextern crate core;if you're using normal rust code any more, socorecan 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 commentedon Sep 4, 2019
Would people be for or against stabilizing the bare
--externflag now? My intent is to automatically issue that flag forproc_macrofor proc-macro crates to avoid the need forextern crate. There hasn't been any visible progress on the transition to themetacrate, 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.
Rollup merge of rust-lang#64882 - ehuss:stabilize-bare-extern, r=eddyb
Rollup merge of rust-lang#64882 - ehuss:stabilize-bare-extern, r=eddyb
Auto merge of #64882 - ehuss:stabilize-bare-extern, r=eddyb
[-]Tracking issue for no more `extern crate` for sysroot crates[/-][+]Don't require `extern crate`[/+]tgross35 commentedon Oct 16, 2023
What is the status of this now that
--externworks?ehuss commentedon Oct 17, 2023
The status is largely unchanged.
Cargo uses
--extern proc_macrofor proc-macro crates so you don't have to doextern proc_macro;.extern crate test;is still required, but all items in thetestcrate are unstable, and the path to stability for anything there is unclear.extern crate std;andextern crate alloc;is still required if you have#![no_std], but want to conditionally includestdoralloc. Cargo does not provide a mechanism to indicate that dependency.extern crate core;is still required if you have#![no_core], same asstd. I don't think this is a particular use-case that we should worry about.