Rust: Tracking issue for Transitioning crates to Rust 2018

Created on 3 Feb 2019  路  17Comments  路  Source: rust-lang/rust

This issue tracks the transitioning of all crates in this repo and sub-modules to Rust 2018.

You can help by filing PRs transitioning a crate at a time to Rust 2018.
When transitioning, please apply the following to the crate root:

#![deny(rust_2018_idioms)]
#![allow(explicit_outlives_requirements)] // Remove or keep this at your option.

You can try to use cargo +nightly fix (or cargo +nightly --edition-idioms) to migrate a crate automatically; see the edition guide for details. However, due to bootstrapping, you might need to do some manual intervention here and there.

If you want to help out, please pick a crate and leave a comment here.
When you make a transitioning PR, also leave a comment here.

cc @rust-lang/compiler @rust-lang/infra

The following crates exist in the repo or as submodules.
Checked items have been transitioned to Rust 2018.

C-tracking-issue T-compiler WG-epoch
Source
picture Centril
👍7 🎉6

Most helpful comment

@pietroalbini @Mark-Simulacrum I'm pleased to announce that all crates, to my knowledge, have been migrated to Rust 2018. As far as I know, all of them have also had idiom lints applied. I think now would be a good idea to apply it globally for rustbuild.

picture Centril on 19 Apr 2019
🎉8

All 17 comments

@Centril

FWIW packed_simd, the old std::simd module, is already using Rust 2018.

stdsimd - cc @gnzlbg; this blocks the transition of libcore

The challenge is that libcore also blocks the transition of stdsimd to the 2018 edition because if we update stdsimd, we can't update rust-lang/rust with a new stdsimd version again until libcore is a Rust2018 crate.

That is, doing this upgrade is going to require some coordination. If someone wants to work on the libcore part of things, it might be a good idea to ping me on Discord / Zulip so that we can talk about the timeline.

Basically, I'll send a PR to stdsimd to update it to the Rust2018 edition but won't merge it. Then somebody can send a PR to rust-lang/rust updating libcore to Rust2018, using the stdsimd branch from my PR. Once that passes all tests, I'll merge the stdsimd PR, and the rust-lang/rust libcore PR can be updated to use stdsimd master, and merged.

gnzlbg picture gnzlbg on 4 Feb 2019

I would like to take a stab at librustc. I had previously played around with it and found it annoying because bootstrap sets some env variables, but I think I might be able to get it this time.

mark-i-m picture mark-i-m on 4 Feb 2019

Some notes as I'm working on this:

  • Compiling librustc requires having some environment variables set. Currently, I'm using

    CFG_COMPILER_HOST_TRIPLE=x86_64-unknown-linux-gnu RUSTC_ERROR_METADATA_DST=/tmp/foo cargo +nightly fix

  • For some reason, I'm unable to compile benchmarks due to weird import errors with libtest. I'm assuming that these are caused by bootstrapping. In this case, I'm temporarily deleting the offending files...

  • You will need to use the --broken-code flag. It turns out that cargo fix has _very weird_ interactions with macros. For example, it tried to make dyn a raw ident in a macro, rather than leaving it alone, leading to compile errors like this:

error: expected one of `!`, `(`, `)`, `,`, `::`, or `<`, found `dep_tracking`
    --> src/librustc/session/config.rs:290:51
     |
290  |                                 $opt_expr as &r#dyn dep_tracking::DepTrackingHash).is_some() {
     |                                                     ^^^^^^^^^^^^ expected one of `!`, `(`, `)`, `,`, `::`, or `<` here
...
1145 | / options! {DebuggingOptions, DebuggingSetter, basic_debugging_options,
1146 | |           build_debugging_options, "Z", "debugging",
1147 | |           DB_OPTIONS, db_type_desc, dbsetters,
1148 | |     codegen_backend: Option<String> = (None, parse_opt_string, [TRACKED],
...    |
1401 | |          the same values as the target option of the same name"),
1402 | | }
     | |_- in this macro invocation

Instead, I'm going to apply the majority of changes using --broken-code. Then, I will go back and fix the problems rustfix introduces... I'm guessing this is a bug, but honestly, I don't even know what to report...

mark-i-m picture mark-i-m on 5 Feb 2019

@gnzlbg

The challenge is that libcore also blocks the transition of stdsimd to the 2018 edition because if we update stdsimd, we can't update rust-lang/rust with a new stdsimd version again until libcore is a Rust2018 crate.

I'd do this by making stdsimd edition-agnostic (compile on both editions). Then libcore can update to 2018 edition and stdsimd can follow.

cramertj picture cramertj on 5 Feb 2019

I'd do this by making stdsimd edition-agnostic (compile on both editions). Then libcore can update to 2018 edition and stdsimd can follow.

Great idea!

gnzlbg picture gnzlbg on 5 Feb 2019

So I've applied cargo fix to core_arch and to std_detect and it reports zero changes, so porting libcore should just work. If someone wants to attempt to port libcore to the Rust2018 edition please ping me if you encounter any issues with stdsimd.

gnzlbg picture gnzlbg on 5 Feb 2019

I'm currently working on the transition of libstd, but I'd like to work on the transition of libcore if that is over (If someone else is not working on it).

taiki-e picture taiki-e on 5 Feb 2019

@Centril It looks like the checklist needs to be updated.

mark-i-m picture mark-i-m on 6 Feb 2019

libstd migration is merged https://github.com/rust-lang/rust/pull/58208

mati865 picture mati865 on 29 Mar 2019

Yep; still waiting on https://github.com/rust-lang/rust/pull/58828 however.

Centril picture Centril on 29 Mar 2019

It should be possible to set the default edition and lints in rustbuild already.
The few remaining crates can opt-out and be transitioned at later time, not necessary to wait for them.

petrochenkov picture petrochenkov on 29 Mar 2019
👍2

@pietroalbini @Mark-Simulacrum I'm pleased to announce that all crates, to my knowledge, have been migrated to Rust 2018. As far as I know, all of them have also had idiom lints applied. I think now would be a good idea to apply it globally for rustbuild.

Centril picture Centril on 19 Apr 2019
🎉8

I can think of a couple of things we want:

  • [ ] tidy-enforced that all new crates are in 2018 edition
  • [x] deny idiom lints

Not entirely sure how best to do the first, but the second should be quite simple -- I would add to https://github.com/rust-lang/rust/blob/master/src/bootstrap/bin/rustc.rs#L307 the deny for idiom lints.

Mark-Simulacrum picture Mark-Simulacrum on 19 Apr 2019

This is done now, right? Can we close this?

mark-i-m picture mark-i-m on 22 May 2019

@mark-i-m

tidy-enforced that all new crates are in 2018 edition

is not done I believe.

Centril picture Centril on 23 May 2019
👍1

Finally done! Maybe tick the checkbox too!

crlf0710 picture crlf0710 on 30 Jul 2019

Finally done! Maybe tick the checkbox too!

crlf0710 picture crlf0710 on 30 Jul 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

dnsl48 picture dnsl48  路  3Comments
zhendongsu picture zhendongsu  路  3Comments
mcarton picture mcarton  路  3Comments
overvenus picture overvenus  路  3Comments
cuviper picture cuviper  路  3Comments