Don't require `extern crate` #57288

mark-i-m · 2019-01-02T21:43:30Z

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.

The text was updated successfully, but these errors were encountered:

cramertj · 2019-01-02T21:50:11Z

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 · 2019-01-02T21:52:52Z

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 · 2019-01-02T21:59:29Z

@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 · 2019-01-02T22:01:51Z

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 · 2019-01-02T22:15:11Z

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 · 2019-01-02T22:17:59Z

@dekellum Indeed-- same issue.

Nemo157 · 2019-01-03T11:03:16Z

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 · 2019-01-03T14:26:35Z

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

petrochenkov · 2019-01-03T14:40:02Z

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 · 2019-01-03T14:43:08Z

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

Nemo157 · 2019-01-03T14:44:19Z

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 · 2019-01-03T14:46:05Z

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 · 2019-01-03T18:31:37Z

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 · 2019-01-09T15:37:33Z

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 · 2019-01-09T16:57:44Z

@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 · 2019-01-09T18:43:33Z

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 · 2019-01-17T20:15:45Z

cc @rust-lang/cargo

SimonSapin · 2019-03-05T09:44:08Z

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 · 2019-07-04T20:56:39Z

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 · 2019-09-04T16:01:19Z

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.

Stabilize --extern flag without a path. This stabilizes the `--extern` flag without a path, implemented in rust-lang#54116. This flag is used to add a crate that may be found in the search path to the extern prelude. The intent of stabilizing this now is to change Cargo to emit this flag for `proc_macro` when building a proc-macro crate. This will allow the ability to elide `extern crate proc_macro;` for proc-macros, one of the few places where it is still necessary. It is intended that Cargo may also use this flag for other cases in the future as part of the [std-aware work](https://github.com/rust-lang/wg-cargo-std-aware/). There will likely be some kind of syntax where users may declare dependencies on other crates (such as `alloc`), and Cargo will use this flag so that they may be used like any other crate. At this time there are no short-term plans to use it for anything other than proc-macro. This will not help for non-proc-macro crates that use `proc_macro`, which I believe is not too common? An alternate approach for proc-macro is to use the `meta` crate, but from my inquiries there doesn't appear to be anyone interested in pushing that forward. The `meta` crate also doesn't help with things like `alloc` or `test`. cc rust-lang#57288

Stabilize --extern flag without a path. This stabilizes the `--extern` flag without a path, implemented in #54116. This flag is used to add a crate that may be found in the search path to the extern prelude. The intent of stabilizing this now is to change Cargo to emit this flag for `proc_macro` when building a proc-macro crate. This will allow the ability to elide `extern crate proc_macro;` for proc-macros, one of the few places where it is still necessary. It is intended that Cargo may also use this flag for other cases in the future as part of the [std-aware work](https://github.com/rust-lang/wg-cargo-std-aware/). There will likely be some kind of syntax where users may declare dependencies on other crates (such as `alloc`), and Cargo will use this flag so that they may be used like any other crate. At this time there are no short-term plans to use it for anything other than proc-macro. This will not help for non-proc-macro crates that use `proc_macro`, which I believe is not too common? An alternate approach for proc-macro is to use the `meta` crate, but from my inquiries there doesn't appear to be anyone interested in pushing that forward. The `meta` crate also doesn't help with things like `alloc` or `test`. cc #57288

tgross35 · 2023-10-16T22:45:23Z

What is the status of this now that --extern works?

ehuss · 2023-10-17T12:02:08Z

The status is largely unchanged.

Cargo uses --extern proc_macro for proc-macro crates so you don't have to do extern proc_macro;.

extern crate test; is still required, but all items in the test crate are unstable, and the path to stability for anything there is unclear.

extern crate std; and extern crate alloc; is still required if you have #![no_std], but want to conditionally include std or alloc. Cargo does not provide a mechanism to indicate that dependency.

extern crate core; is still required if you have #![no_core], same as std. I don't think this is a particular use-case that we should worry about.

mark-i-m mentioned this issue Jan 2, 2019

(Modules) Tracking issue for (use) crate_name:: paths without extern crate #53128

Closed

3 tasks

Centril added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Jan 2, 2019

Centril changed the title ~~[tracking issue] no more extern crate for sysroot crates~~ Tracking issue for no more extern crate for sysroot crates Jan 13, 2019

Centril added the I-nominated label Jan 13, 2019

Centril added T-cargo Relevant to the cargo team, which will review and decide on the PR/issue. needs-rfc This change is large or controversial enough that it should have an RFC accepted before doing it. and removed I-nominated labels Jan 17, 2019

alercah mentioned this issue Jan 31, 2019

Tracking issue for the quote! macro in proc_macro #54722

Open

3 tasks

SimonSapin mentioned this issue Mar 5, 2019

RFC: Stabilize the alloc crate rust-lang/rfcs#2480

Merged

Xanewok mentioned this issue Apr 22, 2019

Tests failing with multiple matching crates for serde rust-lang/rust-clippy#4015

Closed

carols10cents mentioned this issue Jun 13, 2019

Tracking issue for exception about extern crate with sysroot crates rust-lang/edition-guide#168

Open

ehuss mentioned this issue Jul 20, 2019

Cargo standard library dependencies rust-lang/wg-cargo-std-aware#5

Open

dtolnay mentioned this issue Aug 10, 2019

Idea: more intuitive crate name dtolnay/proc-macro2#169

Closed

ehuss mentioned this issue Sep 28, 2019

Stabilize --extern flag without a path. #64882

Merged

joshtriplett removed the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jun 15, 2022

Mark-Simulacrum removed T-cargo Relevant to the cargo team, which will review and decide on the PR/issue. needs-rfc This change is large or controversial enough that it should have an RFC accepted before doing it. labels Jun 15, 2022

Mark-Simulacrum changed the title ~~Tracking issue for no more extern crate for sysroot crates~~ Don't require extern crate Jun 15, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Don't require `extern crate` #57288

Don't require `extern crate` #57288

mark-i-m commented Jan 2, 2019 •

edited by Mark-Simulacrum

Loading

cramertj commented Jan 2, 2019

ehuss commented Jan 2, 2019

mark-i-m commented Jan 2, 2019

cramertj commented Jan 2, 2019 •

edited

Loading

dekellum commented Jan 2, 2019

cramertj commented Jan 2, 2019

Nemo157 commented Jan 3, 2019 •

edited

Loading

mark-i-m commented Jan 3, 2019

petrochenkov commented Jan 3, 2019

petrochenkov commented Jan 3, 2019

Nemo157 commented Jan 3, 2019 •

edited

Loading

petrochenkov commented Jan 3, 2019

mark-i-m commented Jan 3, 2019

alercah commented Jan 9, 2019

cramertj commented Jan 9, 2019

Nemo157 commented Jan 9, 2019

aturon commented Jan 17, 2019

SimonSapin commented Mar 5, 2019

Lokathor commented Jul 4, 2019 •

edited

Loading

ehuss commented Sep 4, 2019

tgross35 commented Oct 16, 2023

ehuss commented Oct 17, 2023

Don't require extern crate #57288

Don't require extern crate #57288

Comments

mark-i-m commented Jan 2, 2019 • edited by Mark-Simulacrum Loading

cramertj commented Jan 2, 2019

ehuss commented Jan 2, 2019

mark-i-m commented Jan 2, 2019

cramertj commented Jan 2, 2019 • edited Loading

dekellum commented Jan 2, 2019

cramertj commented Jan 2, 2019

Nemo157 commented Jan 3, 2019 • edited Loading

mark-i-m commented Jan 3, 2019

petrochenkov commented Jan 3, 2019

petrochenkov commented Jan 3, 2019

Nemo157 commented Jan 3, 2019 • edited Loading

petrochenkov commented Jan 3, 2019

mark-i-m commented Jan 3, 2019

alercah commented Jan 9, 2019

cramertj commented Jan 9, 2019

Nemo157 commented Jan 9, 2019

aturon commented Jan 17, 2019

SimonSapin commented Mar 5, 2019

Lokathor commented Jul 4, 2019 • edited Loading

ehuss commented Sep 4, 2019

tgross35 commented Oct 16, 2023

ehuss commented Oct 17, 2023

Don't require `extern crate` #57288

Don't require `extern crate` #57288

mark-i-m commented Jan 2, 2019 •

edited by Mark-Simulacrum

Loading

cramertj commented Jan 2, 2019 •

edited

Loading

Nemo157 commented Jan 3, 2019 •

edited

Loading

Nemo157 commented Jan 3, 2019 •

edited

Loading

Lokathor commented Jul 4, 2019 •

edited

Loading