Rust 2018 RC1 is available

[steveklabnik]

Edition RC1

Hey everyone! In accordance with the Rust 2018 release schedule, it’s time for the release of the first release candidate for Rust 2018.

To try out Rust 2018 RC1, install the beta toolchain:

> rustup install beta
> rustc +beta --version
rustc 1.30.0-beta.2 (7a0062e46 2018-09-19)

This beta of Rust 1.30 is a bit different than a normal beta: it has the feature flags for Rust 2018 turned on. This means you can kick the tires, and let us know of any issues.

For more information about what you can do with Rust 2018 RC1, please see the Edition Guide. Things that are stable in RC1 are marked as being available in beta, like non-lexical lifetimes!

You’ll probably want to migrate some of your existing code as well as start new projects. If you do these things, please post diffs or links to source, we’d love to check out what things will look like!

I’m happy to answer any questions on this thread.

[aturon]

EDIT: THIS HAS BEEN FIXED: Rust 2018 RC1 is available

---

Unfortunately, this beta release has a critical misfire around the module system, which prevents migration from working. We will be fixing this and producing a point release ASAP.

In the meantime, if you want to try out migration, you need to use nightly and add the following to your crate before running cargo fix --edition:

#![feature(rust_2018_preview)]

After you finish migration, you can remove the attribute.

[m4b]

I posted this on irc about a week ago, but haven’t had time to check/file a bug, but is the misfire related to stuff like this?

https://play.rust-lang.org/?gist=be6979d932f74f624daab2ac179f14a3&version=nightly&mode=debug&edition=2018

Could we also get a link to the problem/issue/misfire in question? Thanks, and really looking forward to the new edition

[steveklabnik]

Could we also get a link to the problem/issue/misfire in question?

The issue is this. The workflow for upgrading your codebase is supposed to be

> cargo +beta fix --edition

Run this until your code compiles with no warnings. Now, your code is valid Rust 2015 and Rust 2018. You should be able to add edition = "2018" to your Cargo.toml, and it will build. You may get new warnings, but it should build.

However, the above does not migrate use statements. This means that after running cargo fix, even once you have warnings, the cargo build after adding the edition key does not compile. This means that you’d have to modify all of your use statements by hand. You can do this, but on a project of non-trivial size, it can be difficult. That’s not an accurate impression of what the final workflow should be.

Uniform paths are not part of the edition; what got stabilized is something forward compatible with them, but the decision to enable that has not yet been made.

[timmyjose]

Is the idea that once the migration has been done, we can get rid of that attribute?

I followed the steps here for my (small) projects, and they gave no errors. However, they do give warnings about this attribute when I try cargo +nightly build afterwards.

[steveklabnik]

Is the idea that once the migration has been done, we can get rid of that attribute?

Yes, you shouldn’t generally need that attribute. The whole point of making rust 2018 stable is that you shouldn’t need this. Great catch!

[timmyjose]

Okay, so I can get rid of that, right? That line gives warnings on nightly, but errors on beta. Sorry, all this is a bit confusing - I have just started reading the Edition Guide that you mentioned earlier.

Thanks for the help!

[steveklabnik]

It’s totaly reasonable that it’s confusing, no worries! That’s why it’s a bug.

So the steps would be, add the attribute, run cargo +nightly fix —edition, then remove the attribute and add the edition flag to cargo.toml.

[timmyjose]

Perfect! That’s exactly what I did now - one project had no errors, the other one had quite a few errors with use, but it was a simple text substitution fix, so no worries!

[jechase]

Apart from the beta hiccup and this issue, the edition migration process is looking pretty good!

Aside from the dangling attributes, I had no trouble migrating our ~7k-loc-over-12-crates project via cargo fix.

One thing I wish there was a better story for is migrating from #[macro_use] imports to use statements.

[eddyb]

Fix PR is up at https://github.com/rust-lang/rust/pull/54403 - turns out we forgot to stabilize path-related features!
(so migrations were implicitly disabled)

[orium]

Could we also get a link to the problem/issue/misfire in question?

I believe it is this: https://github.com/rust-lang/rust/issues/53797

[eddyb]

No, that’s gonna come later. Much more essential migration was unavailable because it required feature gates.

[CAD97]

Playground still forces itself to nightly when you switch to edition=2018.
It’s a small thing, but definitely an issue for sharing edition=2018 code.
https://github.com/integer32llc/rust-playground/issues/411

[steveklabnik]

The situation with use statements has been addressed; you should no longer need a manual fix here!

[theduke]

I see that macro namespaces still work differently for macros defined inside the current module vs dependencies.

I hoped that this would change for the final version but seeing this is still the case for the RC I assume this will stay the same?

This is a major usability/teachability issue in my opinion since now you have to learn both the old and the new system and remember that the old system only applies to your current crate.

Are there any plans to fix this in the near future? But even then, the system would have to stay the same at least until the next edition.

[steveklabnik]

There’s no plans to change macro_rules any more; the fix is for the new macro system to land.

[gbutler]

the fix is for the new macro system to land

Do you know the most recent word on when that is likely to happen?

[steveklabnik]

I’m not sure: maybe @nrc knows?

[petrochenkov]

Crate-local macro_rules work like let at module level for years and cannot be implicitly modularized without large breakage.
Unstable macro items are already modularized.
Suggestions to modularize crate-local macro_rules explicitly with pub existed (https://github.com/rust-lang/rust/issues/35896#issuecomment-299354552, https://github.com/rust-lang/rust/issues/35896#issuecomment-391856772), but never went beyond suggestions.
I suspect the chance of them being implemented correlates positively with time for which macro items will be kept unstable.