Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for edition-specific preludes #85684

Closed
6 tasks done
m-ou-se opened this issue May 25, 2021 · 4 comments
Closed
6 tasks done

Tracking issue for edition-specific preludes #85684

m-ou-se opened this issue May 25, 2021 · 4 comments
Assignees
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@m-ou-se
Copy link
Member

m-ou-se commented May 25, 2021

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

Unresolved Questions

  • None yet.
@m-ou-se m-ou-se added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels May 25, 2021
@m-ou-se m-ou-se self-assigned this May 25, 2021
@m-ou-se m-ou-se changed the title Tracking Issue for the 2021 prelude Tracking issue for edition-specific preludes May 25, 2021
@m-ou-se m-ou-se added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label May 25, 2021
@SimonSapin
Copy link
Contributor

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
Copy link
Member Author

m-ou-se commented May 26, 2021

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

bors added a commit to rust-lang-ci/rust that referenced this issue Jun 2, 2021
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jun 14, 2021
…joshtriplett

Stabilize {std, core}::prelude::rust_*.

This stabilizes the `{core, std}::prelude::{rust_2015, rust_2018, rust_2021}` modules.

The usage of these modules as the prelude in those editions was already stabilized. This just stabilizes the modules themselves, making it possible for a user to explicitly refer to them.

Tracking issue: rust-lang#85684

FCP on the RFC that included this finished here: rust-lang/rfcs#3114 (comment)
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jun 14, 2021
…joshtriplett

Stabilize {std, core}::prelude::rust_*.

This stabilizes the `{core, std}::prelude::{rust_2015, rust_2018, rust_2021}` modules.

The usage of these modules as the prelude in those editions was already stabilized. This just stabilizes the modules themselves, making it possible for a user to explicitly refer to them.

Tracking issue: rust-lang#85684

FCP on the RFC that included this finished here: rust-lang/rfcs#3114 (comment)
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jun 15, 2021
…joshtriplett

Stabilize {std, core}::prelude::rust_*.

This stabilizes the `{core, std}::prelude::{rust_2015, rust_2018, rust_2021}` modules.

The usage of these modules as the prelude in those editions was already stabilized. This just stabilizes the modules themselves, making it possible for a user to explicitly refer to them.

Tracking issue: rust-lang#85684

FCP on the RFC that included this finished here: rust-lang/rfcs#3114 (comment)
@danielhenrymantilla
Copy link
Contributor

danielhenrymantilla commented Jun 18, 2021

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
Copy link
Member Author

m-ou-se commented Jun 22, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants