Skip to content

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

Merged
merged 3 commits into from
Oct 30, 2018
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
131 changes: 131 additions & 0 deletions _posts/2018-10-29-help-test-rust-2018.md
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
Copy link
Member

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:

In short, we are launching a cycle of long-term milestones called "Editions". Editions are a way to capture the progress delivered incrementally by our ordinary six-week release cycle -- and focus Rust libraries, tooling, and documentation cohesively around it. Editions will be selected roughly every three years: Rust 1.0 was "Rust 2015" and Rust 1.31 will be "Rust 2018".

Copy link
Member

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.

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."
Copy link
Member

Choose a reason for hiding this comment

The 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/
[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:
Copy link
Member

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

@ehuss ehuss Oct 30, 2018

Choose a reason for hiding this comment

The 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?

Copy link
Member Author

Choose a reason for hiding this comment

The 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.

Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Member Author

Choose a reason for hiding this comment

The 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?

Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Member Author

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The 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 ellipsis_inclusive_range_patterns, elided_lifetimes_in_paths, and explicit_outlives_requirements: the reader must decide for themself whether that makes me knowledgable or biased.)