Tracking issue for edition-specific preludes

[m-ou-se]

This is a tracking issue for the edition-specific preludes.

RFC: rust-lang/rfcs#3114

Feature gates: prelude_2015, prelude_2018, and prelude_2021.

Public API

// std::prelude and core::prelude

pub mod rust_2015 {
    pub use super::v1::*;
}

pub mod rust_2018 {
    pub use super::v1::*;
}

pub mod rust_2021 {
    pub use super::v1::*;
    pub use crate::iter::FromIterator;
    pub use crate::convert::{TryFrom, TryInto};
}

Steps / History

• RFC: A new prelude for the 2021 edition (trait-only edition) rfcs#3114
• Final commenting period (FCP): A new prelude for the 2021 edition (trait-only edition) rfcs#3114 (comment)
• Add prelude::rust_* and pick one depending on the edition: Edition-specific preludes #82217
• Add the new traits to prelude::rust_2021: New prelude #85687
• Implement migration lint: Tracked in Migration lints for 2021 prelude #84594
• Stabilize the preludes and update the documentation: Stabilize {std, core}::prelude::rust_*. #86294

Unresolved Questions

• None yet.

[SimonSapin]

Stabilize the preludes and update the documentation.

Is there something prelude-specific to stabilize besides allowing any use of the 2021 edition on Stable?

[m-ou-se]

@SimonSapin The modules std::prelude::rust_* are currently unstable. So stabilizing them will make it possible ot refer to those explicitly. Automatically importing the 2021 prelude on edition 2021 is already stable (except that that edition itself isn't stable yet).

[danielhenrymantilla]

Regarding the "how do preludes affect macro hygiene / resolution":

• What is "affect hygiene" referring to? I guess it refers to the fact that if a macro from a crate written in the 2021 edition does TryFrom::try_from(…), in an unqualified fashion, and if that macro is called by a pre-2021 crate which does not explicitly bring TryFrom into scope, then the call will fail? That is normal expected behavior, at least as long as we are dealing with {semi-,}transparent macros (macro_rules! macros, Span::{def,mixed}_site()-using proc-macros, and #[rustc_macro_transparency = "{semi,}transparent"] macros).

  But with properly / fully hygienic macros, such as (…transparency = "opaque") macros or Span::def_site()-using proc-macros, then the item resolution will be performed w.r.t. what was in scope of the macro definition, and in that case it will work. But AFAIK, the prelude plays no special role here, it's just an implicit use … present at both the def site and the call site, and the hygiene of the macro, as with any other items in scope, is the mechanism which decides which use gets used.

• Regarding the "resolution", I suspect that word was used to refer to that previous bullet. That being said, I'd like to "raise awareness" about something brought up in the context of rustdoc, so as to give visibility to the issue within a more appropriate context (prelude / libs discussions).

  Basically, even though we are using an edition-dependent prelude system for non-macro items and some macro items, we are still using the legacy "special macro prelude" for other macro items, such as print…!, format!, and any other #[macro_export] macro_rules! macro

  • with ::std,

    #![no_std]
    
    extern crate std;
    
    use ::std::prelude::v1::*;
    
    fn main ()
    {
        let _ = format_args!(""); // OK: available in the prelude.
        let _ = format!(""); // Error: available at `::std::*`
    }

  • and even in #![no_std] (although these require unstable features, so no back-compat issues at least):

    • with ::alloc,

      #![cfg_attr(all(), feature(alloc_prelude), no_std)]
      
      extern crate alloc;
      
      use ::alloc::prelude::v1::vec; // Error, it's at `::alloc::vec`.
      
      fn main ()
      {
          let _ = vec![]; // Error
      }

    • with ::core,

      #![cfg_attr(all(), feature(no_core), no_core)]
      
      extern crate core;
      
      use ::core::prelude::v1::*;
      
      fn _check()
      {
          let _ = concat!(""); // OK
          let _ = panic!(""); // Error
      }

  Granted, these examples are innocent since they feature currently missing non-trait items in the prelude, which is not an issue; but consider the inverse pattern: instead of not applying #[macro_use] and use-ing the prelude, consider not use-ing the prelude and instead #[macro_use]-ing these crates. This is currently stable for both :std and ::alloc.

  This means that once a #[macro_export]-ed macro (or any other pub macro at the root of the alloc or std crates) is accessible from stable, then it is a semver breaking change to remove them from the root of the crate, and as long as the #[macro_use] statement is implicitly applied onto those standard library crates, then they are effectively part of the prelude.

  I think this situation ought to be mentioned in the RFC, so as to avoid accidental stabilizations of unwanted macro paths. Ideally, "always-in-scope" macros that may be added in the future ought to be so through a re-export from the prelude, by having them be macro macros (like ptr::addr_of{,_mut}!): #[macro_export] macro_rules! ought to be avoided, lest we keep polluting the root of the crate namespace, as well as the #[macro_use] extern crate …;-induced prelude.

[m-ou-se]

@danielhenrymantilla For new macros we try to put them inside a module like ptr::addr_of. But for the existing macros we can't really switch away from the current mechanism without breaking existing code. We could also add them to the preludes, but we can't really remove #[macro_export]. Feel free to open a separate issue if you want.

Closing this issue, as the new edition prelude and all related work is finished.