Consistent no_prelude attribute

[Nemo157]

Implementation of rust-lang/rfcs#501 tracked in #20561.

Adds the no_prelude attribute that stops automatic injecting of the standard prelude in a single module behind a feature gate.
Deprecates the existing no_implicit_prelude.

[Nemo157]

I'm tempted to leave the deprecation until no_prelude is stabilised, these changes mean there's no way to stop injection of the prelude on a stable compiler without a warning. This could be ok though, according to #31900 (comment) no_implicit_prelude shouldn't have been stabilised in the first place.

Since the behaviour of no_prelude and no_implicit_prelude are different I was thinking maybe the deprecation warning should mention this. I haven't given much thought to the wording but that might result in a really long message if there's no easy way to explain the difference.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nrc (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[jseyfried]

Reviewed, LGTM except that I don't think we should deprecate no_implicit_prelude until we've stabilized no_prelude (which shouldn't take very long given its simplicity). @alexcrichton what do you think?

[alexcrichton]

How come there are two warnings emitted here?

[Nemo157]

The feature gate visitor is run twice, once before cfg expansion and once after. I could try and find some way to avoid the double up, but the existing simd attribute deprecation warning does the same.

[alexcrichton]

Hm ok, we probably want to figure out whether we're deprecating or not before going to great lengths to figure this out, and it's probably fine either way.

[alexcrichton]

Thanks @Nemo157! In terms of tests, can you also add a new test to ensure that #![no_prelude] is feature gated?

In terms of deprecation, we have a few possible routes we can take here:

• Deprecate immediately as this PR is doing. The downside is that there is no recourse for users leveraging this attribute on stable Rust.
• Remove entirely immediately. This has the downside of breaking users of the attribute on stable Rust and forcing them to move to nightly.
• Not deprecating until #![no_prelude] is stable. Downside here is that we lengthen the lifespan of #![no_implicit_prelude] by quite a bit.

To me the answer of what to do here kinda depends on if there's any widespread usage of #![no_implicit_prelude]. If there's not actually any usage then we can probably do whatever we want here, but if there is the situation is a little more tricky.

Doing a quick grep over the latest code on crates.io right now I see:

• nailgun 0.1.0
• gtk 0.0.6 - couldn't find in https://github.com/gtk-rs/gtk

So given that we probably can't remove immediately. We may also not be able to deprecate either without stabilizing #![no_prelude].

I'm personally always a fan of more aggressive deprecation, so I'd prefer to deprecate immediately, but others may feel differently!

cc @rust-lang/lang

[bors]

☔️ The latest upstream changes (presumably #30884) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔️ The latest upstream changes (presumably #31954) made this pull request unmergeable. Please resolve the merge conflicts.

[aturon]

See also #32131 (comment)

[alexcrichton]

Nominating for discussion at a lang team meeting (I think I applied the right tags?)

[bors]

☔️ The latest upstream changes (presumably #30652) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

We discussed how to proceed in the @rust-lang/lang meeting. Our feeling was that:

1. We should not deprecate #[no_implicit_prelude] until a stable alternative is available.
2. It's probably not worth it to remove #[no_implicit_prelude]; the code maintenance burden is low. You can simply think of #[no_implicit_prelude] as removing the prelude but substituting a module with the primitive types.

[bors]

☔️ The latest upstream changes (presumably #32875) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Closing due to inactivity, but feel free to resubmit with a rebase!