-
Notifications
You must be signed in to change notification settings - Fork 301
initial draft of 'testing rust 2018' #286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,131 @@ | ||
--- | ||
title: "Help test Rust 2018" | ||
--- | ||
|
||
Back in July, we talked about ["Rust 2018"]. In short, we're adding a new | ||
concept to Rust, "Editions." Editions are a way of showing larger progress | ||
than our six-week release cycle, and will happen on a roughly three-year | ||
cycle. Rust 1.0 was "Rust 2015," and Rust 1.31 will be "Rust 2018." | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd love to mention not just the versions/years, but also the themes: stability and productivity, respectively. |
||
|
||
We've been [testing Rust 2018 for a while already], and things are looking | ||
pretty good! We have just under six weeks until Rust 1.31 ships, and so | ||
we'd appreciate it if you could give the beta a try. | ||
|
||
There's two ways to try out Rust 2018: updating an existing project, and | ||
starting a new one. For full details, please check out the [Edition Guide], | ||
but the rest of this post is a quickstart to make it even easier. In | ||
addition, we have some new lints we'd like you to try; they're described at | ||
the very end of the post. | ||
|
||
If anything goes wrong, or is confusing, please [file an issue] and let us | ||
know. We want to make sure this is an extra-awesome release! Thank you for | ||
helping us make Rust even better. <3 | ||
|
||
["Rust 2018"]: https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html | ||
[testing Rust 2018 for a while already]: https://internals.rust-lang.org/t/rust-2018-release-schedule-and-extended-beta/8076 | ||
[Edition Guide]: https://rust-lang-nursery.github.io/edition-guide/ | ||
Mark-Simulacrum marked this conversation as resolved.
Show resolved
Hide resolved
|
||
[file an issue]: https://github.com/rust-lang/rust/issues/new | ||
|
||
## Setup: install Rust beta | ||
|
||
First things first, you'll need to install the beta release channel of Rust. | ||
With Rustup, it's as easy as: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should link to rustup here. |
||
|
||
```console | ||
$ rustup install beta | ||
``` | ||
|
||
To use this channel of Rust instead of your default, you can append a `+beta` | ||
to any `rustc` or cargo commands: | ||
|
||
```console | ||
$ rustc +beta --version | ||
$ cargo +beta build | ||
``` | ||
|
||
This lets you stick to stable as the default, while using beta for your | ||
experiments. | ||
|
||
## Start a new project | ||
|
||
To start a new project with Rust 2018: | ||
|
||
```console | ||
$ cargo +beta new my-sample-project | ||
``` | ||
|
||
Nothing changes! Well, something changed. Check out `Cargo.toml`: | ||
|
||
```toml | ||
[package] | ||
name = "my-sample-project" | ||
version = "0.1.0" | ||
authors = ["Your Name <[email protected]>"] | ||
edition = "2018" | ||
|
||
[dependencies] | ||
``` | ||
|
||
That new `edition = "2018"` key/value pair means you're working with Rust 2018. | ||
If it doesn't exist, it's the same as `edition = "2015"`, so all | ||
existing projects keep working. | ||
|
||
## Convert an existing project | ||
|
||
You can also convert an existing project to Rust 2018. Remember, none of your | ||
dependencies need to be updated for this to work; Rust 2018 and 2015 | ||
interoperate seamlessly! | ||
|
||
The first step is to run `cargo fix`: | ||
|
||
```console | ||
$ cargo fix --edition | ||
``` | ||
|
||
This will check your code, and automatically fix any issues that it can. | ||
`cargo fix` is still pretty new, and so it can't always fix your code | ||
automatically. If `cargo fix` can't fix something, it will print the warning | ||
that it cannot fix to the console. If you see one of these warnings, you'll | ||
have to update your code manually. See the corresponding section of the | ||
edition guide for help, and if you have problems, please seek help at the | ||
user's forums. | ||
|
||
Keep running `cargo fix --edition` until you have no more warnings. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm curious if this is still needed. Cargo now automatically runs fix up to 4 times until it fails to make progress. Are there still issues with it not reaching completion? EDIT: Or does this mean run it after making manual changes? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, if cargo-fix can't fix an error, you have to fix it manually, and then run it again manually. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, yes, apologies, I think I misread it. |
||
|
||
Congrats! Your code is now valid in both Rust 2015 and Rust 2018! | ||
|
||
Once this is done, you can commit to Rust 2018 by updating | ||
your `Cargo.toml`: | ||
|
||
```toml | ||
[package] | ||
name = "my-sample-project" | ||
version = "0.1.0" | ||
authors = ["Your Name <[email protected]>"] | ||
edition = "2018" | ||
|
||
[dependencies] | ||
``` | ||
|
||
See that `edition = "2018"`? That's what opts you in to the new features. | ||
Set it, `cargo +beta build`, and you should be good to go! | ||
|
||
## Writing idiomatic code | ||
|
||
We have some new lints that suggest using certain idioms in your Rust 2018 | ||
code. We don't have them turned on by default yet. To see what your code would | ||
look like, you can use `cargo fix`: | ||
|
||
```console | ||
$ cargo +beta fix --edition-idioms | ||
``` | ||
|
||
If things look great, or things look terrible, please let us know! We hope to make | ||
these lints warn by default after gaining some experience with them and working | ||
out the bugs. | ||
|
||
> The `--edition-idioms` flag applies only to the "current crate"; if you want | ||
> to run it against a workspace is necessary to use a workaround with `RUSTFLAGS` | ||
> in order to execute it in all the workspace members. | ||
> | ||
> $ RUSTFLAGS='-Wrust_2018_idioms' cargo fix --all | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure we should call out idiom lints at all. We've punted on multiple issues with them IIRC and I don't believe they're ready for a public announcement like this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm, so the point of this is to get feedback from a wide variety of people; wouldn't we want to mention them in order to see how they're currently doing? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe some of these might currently be in "eat your socks" mode which makes me worry that the perspective of new people will be "editions are painful to transition to, the lines work poorly." On the other hand not saying anything might lead to that being a common question... I think I'm leaning towards neutrality on this - that is, whatever you think is best works for me. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe @Centril has some opinions? If they are that bad, I'm okay with not doing it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Mark-Simulacrum @steveklabnik I can see a case for being very conservative about recommendations for the final stable edition release, but I think we should definitely ask people to test the idiom lints when we're explicitly asking people to test things! Note that the most problematic lints were already demoted from the group in rust-lang/rust#52926. My take on the suriviors follows. (Full disclosure: I implemented
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would try to phrase this second sentence differently. As written, "new concept" sounds heavy and sounds like something that increases complexity: "we are adding a new concept: inheritance!" or "we are adding a new concept: monads! Monads are a way of showing larger progress in our grasp of programming!". I would phrase this to feel lighter and deliberate and forward-looking e.g. my quick attempt:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also mention something about breakage here. That was indeed covered in the previous post, but I don't think that's enough.