I tried this out, and it was generally simple and great - looking forward to much more of this style up upgrade in the future!
The only shortcoming I ran into is that it didn’t remove any extern crates for me. I tried each of:
Run cargo +nightly fix --prepare-for 2018 --all-targets --all-features --allow-dirty without any local changes
Add #![feature(rust_2018_preview)] and then do 1.
Add the edition to the Cargo.toml, and then do 2.
Is something expected to remove extern crates? I also didn’t see any warnings about unused ones, but if I removed them myself the code compiled the same…
I re-did the steps with the correct flags and I am still getting some false positive lints (maybe I should bug report)?
main.rs:
//! Rust belt is a 2D video game inspired by Asteroids.
//! It runs atop the Piston game engine for graphics and SDL2 for sound.
#![feature(rust_2018_preview)]
#![warn(rust_2018_idioms)]
extern crate ai_behavior;
extern crate music;
extern crate opengl_graphics;
extern crate piston_window;
extern crate rand;
extern crate sprite;
use piston_window::{OpenGL, PistonWindow, Size, WindowSettings};
use opengl_graphics::GlGraphics;
mod game;
mod menu;
mod settings;
mod story;
/// Creates a new window and runs the game starts the main menu.
fn main() {
let game_title = "Rust Belt";
let game_window_size = Size {
width: 1024,
height: 768,
};
let opengl = OpenGL::V3_2;
let mut window: PistonWindow = WindowSettings::new(
game_title,
[game_window_size.width, game_window_size.height],
).opengl(opengl)
.samples(4)
.exit_on_esc(true)
.build()
.unwrap_or_else(|error| panic!("Failed to build PistonWindow: {}", error));
let mut gl = GlGraphics::new(opengl);
menu::run(&mut window, &mut gl, game_window_size);
}
>cargo +nightly fix --allow-dirty
Checking rust-belt v1.2.0 (file:///C:/Users/User/PycharmProjects/rust-belt)
Fixing src\story.rs (3 fixes)
Fixing src\game\models\vector.rs (8 fixes)
Fixing src\game\mod.rs (9 fixes)
Fixing src\menu.rs (7 fixes)
Fixing src\game\models\mod.rs (7 fixes)
Fixing src\game\models\player.rs (14 fixes)
Fixing src\game\color.rs (9 fixes)
Fixing src\settings.rs (3 fixes)
Fixing src\game\models\bullet.rs (3 fixes)
Fixing src\game\models\asteroid.rs (4 fixes)
warning: unused extern crate
--> src\main.rs:6:1
|
6 | extern crate ai_behavior;
| ^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove it
|
note: lint level defined here
--> src\main.rs:4:9
|
4 | #![warn(rust_2018_idioms)]
| ^^^^^^^^^^^^^^^^
= note: #[warn(unused_extern_crates)] implied by #[warn(rust_2018_idioms)]
warning: `extern crate` is not idiomatic in the new edition
--> src\main.rs:7:1
|
7 | extern crate music;
| ^^^^^^^^^^^^^^^^^^^ help: convert it to a `use`
warning: unused extern crate
--> src\main.rs:8:1
|
8 | extern crate opengl_graphics;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove it
warning: unused extern crate
--> src\main.rs:9:1
|
9 | extern crate piston_window;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove it
warning: `extern crate` is not idiomatic in the new edition
--> src\main.rs:10:1
|
10 | extern crate rand;
| ^^^^^^^^^^^^^^^^^^ help: convert it to a `use`
warning: unused extern crate
--> src\main.rs:11:1
|
11 | extern crate sprite;
| ^^^^^^^^^^^^^^^^^^^^ help: remove it
Finished dev [unoptimized + debuginfo] target(s) in 2.51s
The lints that say help: convert it to a 'use' should all say remove it. Removing the extern crate's allows the project to build and run without warnings. Is this something that should be reported?
I hit this too. I think the cleanest experience is to not require the user to add the #![feature(rust_2018_preview)] themselves.
Rather, invoking cargo fix --prepare-for 2018 should add that to the top of the file as the first fix, and as a marker that it has been run. Is there a reason this shouldn't be done?
Ah yeah, bugs would be great! If you think it’s a lint bug file it at rust-lang/rust, and if you think it’s a cargo-fix bug file it at rust-lang/cargo, and when in doubt file it on Cargo
For now though we’re interested in cataloguing the idioms lint bugs but we’re unlikely to keep recommending it, so those are less critica.
Agreed! Remember though that during the actual transiton (when the edition is stable) there will be no need for this attribute, it'll all be stable anyway.
This is just a temporary step during the preview period
Sure, and at that point it can adjust it again to the stable version of the same flag (which may well be no flag, and it's all driven by the cargo attribute).
Come to think of it, I'll broaden my sugestion, to have it add the Cargo.toml changes as well. The --prepare-for user experience becomes: "Hey cargo, please set this workspace up for edition X", and all the changes get made (to a clean base, so they can be reviewed before committing or rolling back).
Yeah, I know, but temporary doesn't have to mean manual, or fiddly, or knowing exactly which variant of temporary measures is necessary for the particular toolchain I'm running today. I can imagine someone in a few months time getting a similar paper-cut from following a blog post that still talks about this temporary measure, or reading about the new edition being stable, but they have a slightly older compiler because of distro lag, or other similar cases.
