Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not apply #[macro_use] to implicitly injected extern crate std;, use standard library prelude instead #53977

Open
petrochenkov opened this issue Sep 5, 2018 · 0 comments
Assignees
Labels
A-resolve Area: Path resolution T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@petrochenkov
Copy link
Contributor

Macros like vec or println are currently automatically available to user code through injected standard library

#[macro_use]
extern crate std;

#[macro_use] puts all the macro names into macro prelude, so they are available in inner modules without additional imports.

It would be good to avoid this, especially given that #[macro_use] is going to be gradually deprecated.
We have analogous way to put things into prelude for non-macro namespaces - standard library prelude std::prelude::v1, all stable library macros can be reexported through it instead of #[macro_use] in backward-compatible way.
Undesirable unstable macros like select can be removed from prelude in the process.

The only issue is that several imports for several macros (env, vec, panic) would also import corresponding modules from the standard library (std::env, std::vec, std::panic) and put them into prelude. This is certainly not desirable.

The solution is to come up with some way for a use item to import the name only in the single selected namespace, something like

use a::b in type;
use a::b in macro;
use a::b in value;

Alternatively, this can be done with hacks for cross-crate scenarios (stdlib prelude is indeed a cross-crate scenario).

(All of this is applicable to libcore as well.)

@petrochenkov petrochenkov added A-resolve Area: Path resolution T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Sep 5, 2018
kennytm added a commit to pietroalbini/rust that referenced this issue Nov 11, 2018
resolve: Filter away macro prelude in modules with `#[no_implicit_prelude]` on 2018 edition

This is a tiny thing.
For historical reasons macro prelude (macros from `#[macro_use] extern crate ...`, including `extern crate std`) is still available in modules with `#[no_implicit_prelude]`.
This PR provides proper isolation and removes those names from scope.

`#[no_implicit_prelude]` modules still have built-in types (`u8`), built-in attributes (`#[inline]`) and built-in macros (`env!("PATH")`) in scope. We can introduce some `#[no_implicit_prelude_at_all]` to remove those as well, but that's a separate issue.

The change is done only on 2018 edition for backward compatibility.
I'm pretty sure this can be done on 2015 as well because `#[no_implicit_prelude]` is rarely used, but I don't want to go through the crater/deprecation process right now, maybe later.

cc rust-lang#53977
r? @ghost
@petrochenkov petrochenkov self-assigned this Mar 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-resolve Area: Path resolution T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

1 participant