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.

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

[petrochenkov]

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

Not really.

Are there regressions not related to panics?
I suggest making an abridged version of this change that moves everything except panic from macro_use to stdlib prelude, and looking if something breaks in that case.

[Amanieu]

Most of the failures are due to panic, but I've collected the ones that aren't:

• Some crates are using the unstable format_args_nl. Not re-exporting this is fine since it is doc(hidden) and for internal use.
• In Explicitly export core and std macros #139493 (comment) I show an example with dbg conflicting nom::dbg, but the latter has been renamed in the latest version of nom (Nom breaks dbg macro from std rust-bakery/nom#1022).
• ipcrypt is somehow using assert_eq! without an explicit import and with #![no_implicit_prelude]. (Crater log)
• gcode and dmidecode have conflicting imports of assert_eq from both the standard library and pretty_assertions. One of these is via #[macro_use] extern crate pretty_assertions which is then re-imported with use super::*, the other has an explicit import via use pretty_assertions::assert_eq.
• threescalers has an internal version of matches which creates ambiguity with the one in the prelude. This copy has been removed in the Github repo back in 2022 but no new version of the crate has been released since then.

If we can find a solution for the panic case then I think there are few enough regressions that we can get away with this change by fixing the affected crates.

[Amanieu]

However just not re-exporting panic won't work since this PR removes #[macro_use] on the implicit crate import from the prelude.

[petrochenkov]

However just not re-exporting panic won't work since this PR removes #[macro_use] on the implicit crate import from the prelude.

It could use #[macro_use(panic)] instead of removing.
(Not sure whether it's needed on both std and core to avoid the regressions, or just one of them would be enough.)

[Voultapher]

Before bringing in #[macro_use] back in, could we please run a timing run. I don't think I have the rights to start one myself.

[Voultapher]

Adding a warning about the unintuitive resolution might be good idea. It would move actively developed crates towards an explicit import, allowing for an eventual removal of the panic special casing and it would also help closed source projects not on crates.io, something we couldn't fix by upstreaming patches to the affected crates.

[Kobzol]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: f65cc8e (f65cc8e92b3e9d34b4cc0974ffc1db7476c6dee0, parent: 6f34f4ee074ce0affc7bbf4e2c835f66cd576f13)

[rust-timer]

Finished benchmarking commit (f65cc8e): comparison URL.

Overall result: ❌✅ regressions and improvements - BENCHMARK(S) FAILED

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

❗ ❗ ❗ ❗ ❗
Warning ⚠️: The following benchmark(s) failed to build:

• issue-46449
• runtime:css

❗ ❗ ❗ ❗ ❗

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.6%, 0.6%]	1
Regressions ❌ (secondary)	0.4%	[0.2%, 0.6%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	2
All ❌✅ (primary)	0.6%	[0.6%, 0.6%]	1

Max RSS (memory usage)

Results (primary 1.0%, secondary 0.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.9%	[2.9%, 2.9%]	1
Regressions ❌ (secondary)	2.5%	[1.1%, 5.1%]	11
Improvements ✅ (primary)	-0.8%	[-0.8%, -0.8%]	1
Improvements ✅ (secondary)	-2.8%	[-6.2%, -1.1%]	6
All ❌✅ (primary)	1.0%	[-0.8%, 2.9%]	2

Cycles

Results (secondary -2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.4%	[-2.9%, -1.8%]	3
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.0%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	8
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.0%]	8

Bootstrap: 471.619s -> 472.552s (0.20%)
Artifact size: 388.14 MiB -> 388.13 MiB (-0.00%)