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

r? @Amanieu

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

See also:

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

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

@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

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.

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

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

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

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

@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.

@petrochenkov Do you have any ideas about that?

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

@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.

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.

From a user perspective we are taking code that passed without warnings or errors and are adding a future incompatible warning. I don't see how it's legitimately erroneous code when viewed from a Rust user perspective.

Purely from the language perspective, some ambiguities between preludes that previously produced hard errors now produce lints.
But I agree that it's more practical to see the set of language rules together with the specific prelude names as a whole, that's closer to the user's point of view.

I again suggest splitting this work into two parts - first moving everything except panic, and then dealing with panic separately.

The panic part is the most annoying aspect of this change. In my experience, if we move the annoying part into some separate change it will linger forever. If we can't figure out how to deal it with it here we likely won't in the separate change, and most importantly who will work on it? I've been at this PR for 6 month now, and I don't know if I have the motivation to keep going indefinitely.

The work is already done (I don't see any significantly better fixes to the panic problem than what this PR does), it just needs to be split into two parts landed ~1 release apart, that can be reverted individually, have separate dedicated crater runs and team approvals. The prelude move and the panic hack are two different changes.

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.)

Possible combinations of panic locations:

If I'm not mistaken, in libcore panic can be moved to prelude without issues, only in libstd it still needs to be introduced through macro_use.