Explicitly export core and std macros

[Voultapher]

Currently all core and std macros are automatically added to the prelude via #[macro_use]. However a situation arose where we want to add a new macro assert_matches but don't want to pull it into the standard prelude for compatibility reasons. By explicitly exporting the macros found in the core and std crates we get to decide on a per macro basis and can later add them via the rust_20xx preludes.

Closes #53977
Unlocks #137487

[rustbot]

r? @ChrisDenton

rustbot has assigned @ChrisDenton.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Voultapher]

r? @Amanieu

[Voultapher]

@Amanieu the tidy issue highlights an annoying and unforeseen side-effect of this change. The vec module is now part of the prelude. In effect this means that for example this code:

fn xx(i: vec::IntoIter<i32>) {
    let _ = i.as_slice();
}

fn main() {}

that currently doesn't compile on stable would now compile. Initially I thought this would cause name collisions if users define their own vec module but so far I wasn't able to produce those, it seems to always prefer the local module. But regardless, I think we don't want to allow access to a standard library namespace without going through std, alloc or core. AFAIK there is no way to pub use only the macro and not the module namespace without modifications. I have two ideas how to tackle this, maybe we can rename vec to vec_xx internally and have separate use expressions or we have to add another crate that we can #[macro_use] inject into the prelude that only contains the vec macro. Thoughts?

[traviscross]

See also:

• 2024 edition prelude item docs are not inlined, and cause some duplication and confusion #136102

[petrochenkov]

There's an issue for this change - #53977.

[dtolnay]

@Voultapher, avoiding the vec module re-export can be done like this:

#[macro_export]
macro_rules! myvec {
    () => {};
}

pub mod myvec {
    pub struct Vec;
}

pub mod prelude {
    // Bad: re-exports both macro and type namespace
    // pub use crate::myvec;
    
    mod vec_macro_only {
        #[allow(hidden_glob_reexports)]
        mod myvec {}
        pub use crate::*;
    }
    pub use self::vec_macro_only::myvec;
}

fn main() {
    prelude::myvec!();
    let _: prelude::myvec::Vec; // error
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=5e50828c593e04ba0e98f48c9d8696b4

[Voultapher]

I've applied the suggestion by @dtolnay local tests seem promising. @Kobzol could we please do a timer run to see if this PR impacts compile-times.

[petrochenkov]

env and panic (and maybe something else now?) need to be treated in the same way as vec.

[Kobzol]

@Voultapher Based on the CI failure I think that a try build would fail now.

[Voultapher]

Ok, I'll try to get the CI passing first.

[Voultapher]

@petrochenkov I went through all macros and searched the docs and env and panic seem to be the only other ones affected.

[Voultapher]

@Amanieu this program previously worked:

use std::*;

fn main() {
    panic!("panic works")
}

and now runs into:

error[E0659]: `panic` is ambiguous
   --> src/main.rs:4:5
    |
4   |     panic!("panic works")
    |     ^^^^^ ambiguous name
    |
    = note: ambiguous because of a conflict between a name from a glob import and an outer scope during import or macro resolution
note: `panic` could refer to the macro imported here
   --> src/main.rs:1:5
    |
1   | use std::*;
    |     ^^^^^^
    = help: consider adding an explicit import of `panic` to disambiguate
    = help: or use `crate::panic` to refer to this macro unambiguously
note: `panic` could also refer to the macro defined here
   --> rust/library/std/src/prelude/mod.rs:157:13
    |
157 |     pub use super::v1::*;
    |             ^^^^^^^^^

I don't see how we can resolve that without changing language import rules and or special casing the prelude import.

[Amanieu]

@petrochenkov Do you have any ideas about that?

[petrochenkov]

Could you add a test making sure that the modules vec, env and panic are not in prelude?

[petrochenkov]

@petrochenkov Do you have any ideas about that?

The ambiguity wouldn't happen if it was the same panic in std root and in the stdlib prelude.
However, std and core have two different panic macros.

Previously #[macro_use] extern crate std; would add the std's panic to macro_use prelude, and #[macro_use] extern crate core; would add the core's panic.
This PR always adds the core's panic.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Voultapher]

@rustbot ready

[Amanieu]

This likely needs a crater run.

@bors try

[rust-bors]

☀️ Try build successful (CI)
Build commit: ec62ac6 (ec62ac61f0f5e721f5059579f6a881ef2a3a6c75, parent: 0c0c58b8e453f552ebd7f3a1545acdd109de028c)

[Amanieu]

@craterbot check

[craterbot]

👌 Experiment pr-139493 created and queued.
🤖 Automatically detected try build ec62ac6
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-139493 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-139493 is completed!
📊 61375 regressed and 1 fixed (701952 total)
📊 1370 spurious results on the retry-regessed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

Footnotes

1. re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-139493/retry-regressed-list.txt ↩

[Amanieu]

I had a quick look at the regressions. A lot of them are no_std crates which also explicitly import the std prelude in tests using this:

use std::prelude::v1::*;

This causes macros like panic to be ambiguous since it could refer either to core::panic in the prelude or the imported std::panic.

Example crate: https://github.com/Noratrieb/rustv32i/blob/main/rvdc/src/lib.rs#L1954
Crater report: https://crater-reports.s3.amazonaws.com/pr-139493/try%23ec62ac61f0f5e721f5059579f6a881ef2a3a6c75/gh/Noratrieb.rustv32i/log.txt

[Voultapher]

Given that core::panic and std::panic don't have the exact same semantics, what's the ideal behavior is such a scenario?

Here is a minimal reproducer for the issue:

#![no_std]

extern crate std;
use std::prelude::v1::*;

fn xx() {
    panic!(&String::new()); // resolves to core::panic
}

The old behavior can be restored by adding use core::panic;. I'd argue that in the reproducer it's not exactly clear which panic is meant and maybe not directly intuitive that it still resolves to core::panic even after use std::prelude::v1::*;.

That said, breaking 10% of crates isn't great, even if it is only 95 root crates.

[traviscross]

That said, breaking 10% of crates isn't great, even if it is only 95 root crates.

It might be worth going ahead and making the PRs to these 95 crates. Even if we don't break them (for now at least), they're relying on a resolution which is rather surprising, so they'd be better off in any world doing this explicitly.

That might later give us more options.

[Voultapher]

Good point, I'll do that.

[Amanieu]

Note that std::panic is a strict superset of core::panic in that it supports more inputs (and even then, only on pre-2021 editions), so it's fine if we always resolve to std::panic here.

The main difference between them is that on older editions panic! accepted any type and would simply use that in a Box<dyn Any> as the panic payload. Today you need to do this using the panic_any function.

[traviscross]

In broad strokes, this also seems related to:

• Permit duplicate imports #141043

In this case, the two panic macros aren't exactly the same item, but it seems conceptually that, at least in Rust 2021 and later, they perhaps could be.

[Amanieu]

I don't think this should be blocked on resolving #141043. This is an issue of name resolution priority: currently, prelude macros have a higher priority than glob-imported macros. We need to preserve this property for macros imported via glob imports marked with #[prelude_import].

Here's a different example:

[INFO] [stdout] error[E0659]: `dbg` is ambiguous
[INFO] [stdout]    --> src/java/class_file/parser.rs:259:5
[INFO] [stdout]     |
[INFO] [stdout] 259 |     dbg!(do_parse!(
[INFO] [stdout]     |     ^^^ ambiguous name
[INFO] [stdout]     |
[INFO] [stdout]     = note: ambiguous because of a conflict between a name from a glob import and an outer scope during import or macro resolution
[INFO] [stdout] note: `dbg` could refer to the macro imported here
[INFO] [stdout]    --> src/java/class_file/parser.rs:1:5
[INFO] [stdout]     |
[INFO] [stdout]   1 | use nom::*;
[INFO] [stdout]     |     ^^^^^^
[INFO] [stdout]     = help: consider adding an explicit import of `dbg` to disambiguate
[INFO] [stdout]     = help: or use `self::dbg` to refer to this macro unambiguously
[INFO] [stdout] note: `dbg` could also refer to a macro from prelude
[INFO] [stdout]    --> /rustc/ec62ac61f0f5e721f5059579f6a881ef2a3a6c75/library/std/src/prelude/mod.rs:123:13

nom::dbg imported via nom::* becomes ambiguous with the dbg from the prelude.

[Voultapher]

Note that std::panic is a strict superset of core::panic in that it supports more inputs

While that's not 100% correct, given that Rust 2018 panic!(&String::new() is accepted by core::panic but not std::panic in practice and essence it's true.

Thinking a bit longer about the idea of sending patches to various projects that have the unintuitive core::panic resolution does not really seem worth it. A, it won't really help us here unless we plan to let this PR linger for years until enough of the ecosystem has upgraded to newer dependencies with the fix. B, while it might be a surprising resolution, it does not have surprising effects in practice, so it's harmless.

I agree with @Amanieu that we should fix this in the resolver.

[Amanieu]

Unfortunately I think this boils back down to the original issue that this PR has been trying to avoid, which is prioritization between glob imports and prelude macros.

@petrochenkov Any thoughts on how we might be able to fix this?