Announcing Rust 2018 Beta release!


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)
rls-preview-x86_64-unknown-linux-gnu (installed)
rustfmt-preview-x86_64-unknown-linux-gnu (installed)


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


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


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 :slight_smile:

Thanks again, very excited for 2018!


… And an ICE that happens in both beta and nightly presumably in code around name resolution in the new path system…


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


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




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?

split this topic #11

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


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


What’s the issue number for that?


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


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


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.



#![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

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.


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


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?


Probably yes, because the question arises regularly.

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.

closed #21

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.