Change:
<ins> //! Tidy check to ensure that crate `edition` is '2018' //! use std::path::Path; fn filter_dirs(path: &Path) -> bool { // FIXME: just use super::filter_dirs after the submodules are updated. if super::filter_dirs(path) { return true; } let skip = [ "src/doc/book/second-edition", "src/doc/book/2018-edition", "src/doc/book/ci/stable-check", "src/doc/reference/stable-check", ]; skip.iter().any(|p| path.ends_with(p)) } fn is_edition_2018(mut line: &str) -> bool { line = line.trim(); line == "edition = "2018"" || line == "edition = '2018'" } pub fn check(path: &Path, bad: &mut bool) { super::walk( path, &mut |path| filter_dirs(path) || path.ends_with("src/test"), &mut |entry, contents| { let file = entry.path(); let filename = file.file_name().unwrap(); if filename != "Cargo.toml" { return; } let has_edition = contents.lines().any(is_edition_2018); if !has_edition { tidy_error!( bad, "{} doesn't have `edition = "2018"` on a separate line", file.display() ); } }, ); } </ins>

Discussion:
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: You can try to use (or ) to migrate a crate automatically; see the 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 The following crates exist in the repo or as submodules. Checked items have been transitioned to Rust 2018. [x] bootstrap [x] buildhelper; done in [x] liballoc; done in [x] libarena; done in [x] libcore; done in [x] libfmtmacros; done in [x] libgraphviz; done in [x] libpanicabort; done in [x] libpanicunwind; done in [x] libprocmacro; done in [x] libprofilerbuiltins; done in [x] librustc; done in [x] librustcallocator; done in [x] librustcapfloat; done in [x] librustcasan; done in [x] librustcborrowck; done in [x] librustccodegenllvm; done in [x] librustccodegenssa; done in [x] librustccodegenutils; done in [x] librustccratesioshim; done in [x] librustcdatastructures; done in [x] librustcdriver; done in [x] librustcerrors; done [x] librustcfsutil; done in [x] librustcincremental; done in [x] librustcinterface; done in [x] librustclint; done in [x] librustcllvm; done in [x] librustclsan; done in [x] librustcmetadata; done in [x] librustcmir; done in [x] librustcmsan; done in [x] librustcpasses; done in [x] librustcplugin; done in [x] librustcprivacy;

done in [x] librustcresolve; done in [x] librustcsaveanalysis; done in [x] librustctarget; done in [x] librustctraits; done in [x] librustctsan; done in [x] librustctypeck; done in [x] librustdoc; done in [x] libserialize; done in [x] libstd; done in [x] libsyntax; done in [x] libsyntaxext; done in [x] libsyntaxpos; done in [x] libterm; done in [x] libtest; done in [x] libunwind; done in [x] rustc [x] stdsimd tools [x] build-manifest; done in [x] cargo - submodule: [x] cargo-test; done in [x] clippy - submodule: [x] clippydev [x] clippydummy [x] clippylints [x] clippyworkspacetests; fixed in [x] mini-macro; fixed in [x] rustctoolsutil [x] compiletest; done in [x] errorindex_generator; done in [x] linkchecker; done in [x] miri - submodule: [x] remote-test-client; done in [x] remote-test-server; done in [x] rls - submodule: [x] rust-installer [x] rustbook [x] rustc-std-workspace-core; done in [x] rustc-workspace-hack; done in [x] rustdoc; done in [x] rustdoc-themes; done in [x] rustfmt - submodule: [x] tidy; done in [x] unstable-book-gen; done in
FWIW , the old module, is already using Rust 2018. The challenge is that also blocks the transition of to the 2018 edition because if we update , we can't update rust-lang/rust with a new stdsimd version again until is a Rust2018 crate. That is, doing this upgrade is going to require some coordination. If someone wants to work on the 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.
I would like to take a stab at . 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.
Some notes as I'm working on this: Compiling librustc requires having some environment variables set. Currently, I'm usingFor some reason, I'm unable to compile benchmarks due to weird import errors with . 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 flag. It turns out that has very weird interactions with macros. For example, it tried to make a raw ident in a macro, rather than leaving it alone, leading to compile errors like this: Instead, I'm going to apply the majority of changes using . 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...
I'd do this by making edition-agnostic (compile on both editions). Then libcore can update to 2018 edition and can follow.
Great idea!
So I've applied to and to 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 .
I'm currently working on the transition of , but I'd like to work on the transition of if that is over (If someone else is not working on it).
It looks like the checklist needs to be updated.
migration is merged
Yep; still waiting on however.
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.
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.

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 the deny for idiom lints.
This is done now, right? Can we close this?
is not done I believe.
Finally done! Maybe tick the checkbox too!
Finally done! Maybe tick the checkbox too!