Rust 2018 RC1 is available

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.

1 Like

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!

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

2 Likes

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

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.

1 Like

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!

1 Like

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.

2 Likes

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)

2 Likes

I believe it is this: Rustc does not warn about `use` with paths incompatible with `uniform_paths` for edition 2018 · Issue #53797 · rust-lang/rust · GitHub

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

1 Like

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

2 Likes

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

1 Like

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.

1 Like

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

1 Like

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

I’m not sure: maybe @nrc knows?

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.

1 Like

cargo fix seems to just convert the extern crate into use crate, it works even after I removed the use crate generated by cargo.

It would be nice if cargo automatically convert #[macro_use] extern crate serde into use serde::Serialize though.

5 Likes

Where could we realistically have a warning if edition = is not set in Cargo.toml?

I just wanted to share a data point, that I recently converted rust-belt, a small Piston game, to Rust 2018 using the current beta. This game has over a 100 transitive dependencies, and the experience was great!

Release compile times are normally about 120 seconds, and Rust 2018 was only a few seconds slower (~2%) (with NLL!). I consider this to be a monumental success.

With cargo fix installed by default and ready to go, following the edition guide was a breeze. This was far, far easier than any similar port in any other language I’ve ever used. The fact that Rust 2015 and 2018 crates interop seamlessly is also quite impressive. This is equivalent to depending a C++17 library from C++03, something I’d never even thought to ask for given how wildly inconceivable it would be in C++'s current compilation model.

So a big thanks and congrats to the whole team :clap:!

25 Likes

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