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.

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

[Amanieu]

What collision is this? Is this something that user code is likely to encounter?

[Voultapher]

Here is the error that I get when not making this change:

error[E0659]: `panic` is ambiguous
   --> library/proc_macro/src/bridge/symbol.rs:41:17
    |
41  |                 panic!("`{}` cannot be a raw identifier", string);
    |                 ^^^^^ 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
   --> library/proc_macro/src/bridge/symbol.rs:19:5
    |
19  | use super::*;
    |     ^^^^^^^^
    = help: consider adding an explicit import of `panic` to disambiguate
    = help: or use `self::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::*;
    |             ^^^^^^^^^

My reasoning is a follows, this special proc macro is built together with std which gives access to std via super, causing the import ambiguity. I don't think this is an issue for user code since normal crates can't access std via super - I checked - and I assume normal proc macros can't either, but I'm no expert in that area.

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

  = note: `-D unused-qualifications` implied by `-D warnings`
  = help: to override `-D warnings` add `#[allow(unused_qualifications)]`
help: remove the unnecessary path segments
  |
6 - pub struct IdentIter(std::vec::IntoIter<Ident>);
6 + pub struct IdentIter(vec::IntoIter<Ident>);
  |

[RUSTC-TIMING] unicode_width test:false 0.158
    Checking futures-sink v0.3.31
[RUSTC-TIMING] futures_sink test:false 0.041

[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