Announcing Rust 2018 Beta release!


#2

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)

#3

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


#4

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


#5

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

Thanks again, very excited for 2018!


#6

… 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


#7

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


#8

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


#9

Yes


#10

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


#12

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


#13

What’s the issue number for that?


#14

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


#15

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


#16

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.


#17

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


#18

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


#19

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?


#20

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.