Announcing Rust 2018 Beta release!

[nikomatsakis]

Hello everyone,

It is my pleasure to announce that we have now entered the final countdown for Rust 2018. We’ve just issued a new beta that is chock full of updates and we would dearly love people to spend some time testing it before we announce the final release (which takes place on December 6).

What’s new

Compared to the Preview 2 release, this new 1.31.0 beta includes all the features we stabilized in 1.31.0 and a lot of bug fixes. It also includes a number of improvements in the area of tooling:

• Rustfmt is now 1.0
• RLS and Clippy are no longer installed via “preview” components
  • Update: Apparently this isn’t quite true yet, and we are waiting on a rustup update here still

Help us find bugs!

We would like help looking for bugs in this new beta, particularly in two areas:

• the module system implementation
• the RLS

As before, the best thing is to perform the Rust 2015 -> Rust 2018 migration on your local crates (instructions here) and let us know how it goes (in particular if you hit any problems). If you’ve already migated, then simply executing rustup update beta is already helpful (and working from beta, of course, not nightly)!

Pending for the next release

You may recall from the Preview 2 announcement that we were evaluating two variants for the module system (“anchored paths” vs “uniform paths”). This evaluation continues in the beta, which means that the compiler accepts only code that both variants would accept. You can use #![feature(uniform_paths)] on Nightly to try out the uniform paths variant. Based on the feedback receiver thus far, the current tentative plan is to stabilize uniform paths, but not as part of the initial Rust 2018 release (i.e., not until 1.32.0 at the earliest).

(The main difference between that two variants is that uniform_paths permits you to write use foo::bar to refer to either an external crate named foo or a local module. In other words, you no longer need to write use self::foo::bar (except for cases of ambiguity, where there exists an external crate and a local module). This means that paths in use statements and paths outside of use statements work roughly the same way. Note that this is a pure extension of the current beta behavior, which always requires use self::foo for local modules, but still errors in the case of ambiguity.)

[cuviper]

• RLS and Clippy are no longer installed via “preview” components

Did this misfire? I updated to 1.31.0-beta.17, but I still see only “preview” tools:

$ rustup component list --toolchain beta | grep preview
clippy-preview-x86_64-unknown-linux-gnu (installed)
llvm-tools-preview-x86_64-unknown-linux-gnu
rls-preview-x86_64-unknown-linux-gnu (installed)
rustfmt-preview-x86_64-unknown-linux-gnu (installed)

[nikomatsakis]

I don’t know =) perhaps I was mistaken. (cc @nrc, @alexcrichton)

[nrc]

It’s waiting on a Rustup update actually. It will hopefully happen early this week.

[illicitonion]

This update was super smooth to try out; huge kudos for all of the cargo fix work, it’s wonderful!

I ran into one issue with cargo fix --edition-idioms: report and minimal repro at https://github.com/rust-lang/cargo/issues/6353

Thanks again, very excited for 2018!

[illicitonion]

… And an ICE that happens in both beta and nightly presumably in code around name resolution in the new path system… https://github.com/rust-lang/rust/issues/56263

[jonhoo]

RLS and Clippy are no longer installed via “preview” components

Will this also be the case for nightly after this hits rustup for beta?

[VitalyAnkh]

Then Rust 1.32.0 becomes the most exciting version… I think we can name Rust 1.32.0 as Rust 2019…

[nrc]

RLS and Clippy are no longer installed via “preview” components

Yes

[huxi]

The #[cfg_attr(rustfmt, rustfmt_skip)] => #[rustfmt::skip] clippy warning is still only showing up in nightly even though #[rustfmt::skip] has been available since 1.30.

Wouldn’t it make sense to include this rule in the initial edition 2018 clippy?

[mbrubeck]

9 posts were split to a new topic: Installing docs is slow on Windows

[vlisivka]

Incompatibility with C in C-style enum’s is still not fixed.

[josh]

What’s the issue number for that?

[vlisivka]

For C-enum like enum’s, this one maybe:

Pre-RFC enum from integer

Sure, there’s enum_primitive using macros 1.0, and enum-primitive-derive and num-derive using custom derive – all targeting FromPrimitive. I’m sure TryFrom could be derived the same way, although automatically writing this for just the repr type is harder, since we don’t have that type info AFAIK.

[alexcrichton]

The Rust 2018 (1.31.0) release itself is now ready for testing for anyone who’s extra intrepid!

[johnthagen]

I had opened an issue asking for some further explanation on why #![macro_use] is needed for local macros in the edition guide tracker. I never got any comments so I just wanted to make sure it didn’t get overlooked.

[petrochenkov]

@johnthagen

#![macro_use] is needed for local macros

Long story short - macro_rules! acts like let variables, but at module level, so there can be many of them having the same name in a single module and shadowing each other.
For use module::my_macro to work with local macro_rules! we need to decide what my_macro exactly it refers to (probably the last one) and how to do it without causing import resolution to stuck.

#[macro_export] macro_rules! on another hand defines two names actually, one usual let-like macro_rules and one item-like name in the root module that can be imported with use.
That’s why you can’t define multiple #[macro_export] macro_rules! with the same name in the same crate.

---

With uniform paths on 2018 edition there’s a way to make macro_rules! item modularized explicitly

macro_rules! foo { () => () } // `let`-like macro

pub(crate) use foo; // item-like reexport of the `let`-like macro

, but some tweaks to macro_rules! privacy need to be done first (as described in https://github.com/rust-lang/rust/issues/56417).

Perhaps there’s a way to add this reexport automatically, but this certainly cannot be done naively because it will break the multiple shadowing macro_rules! in the same module.

[johnthagen]

Long story short

@petrochenkov Thanks for the explanation! Do you think some condensed version of this belongs in the edition guide (even a one-liner about shadowing issues)?

[SimonSapin]

This clarified my mental model a lot, thank you! What about #[macro_use] on a mod item? Does it expand the let-like scope to “continue” in the rest of the parent module, and later sibling modules?

[petrochenkov]

Do you think some condensed version of this belongs in the edition guide (even a one-liner about shadowing issues)?

Probably yes, because the question arises regularly.

What about #[macro_use] on a mod item? Does it expand the let -like scope to “continue” in the rest of the parent module, and later sibling modules?

Yes, by default the closing brace } on module or block terminates macro_rules scopes, but #[macro_use] on mod opts-out of this default and lets the scopes continue further.

Unlike let variables macro_rules don’t have any runtime behavior/lifetimes/destructors attached to the scope end, so letting them out doesn’t cause any issues.