-
Notifications
You must be signed in to change notification settings - Fork 293
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
initial draft of 'testing rust 2018' #286
Conversation
## 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 comment
The reason will be displayed to describe this comment to others. Learn more.
We should link to rustup here.
> 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 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.
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.
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 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.
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.
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 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.)
-
bare_trait_objects
: no problems that I'm aware of? -
unused_extern_crates
: false-positives reported in edition idioms lints:unused_extern_crate
false positives rust#53964 (someone should take a look at this) -
ellipsis_inclusive_range_patterns
: the suggestion is currently marked as not-auto-fixable, but the blocking issue there has been resolved—it's likely I could make it machine-applicable this week -
elided_lifetimes_in_paths
: no problems that I'm aware of? -
explicit_outlives_requirements
: some false-negatives (fix false negatives in explicit_outlives_requirements rust#54630), and disambiguate between multiple suggestions and a single multi-span suggestion; or, JSON error format is not round-trippable rust#53934 is a blocker for adding multi-span suggestion support to rustfix
--- | ||
|
||
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 |
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:
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".
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.
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 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.
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 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?
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.
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 comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes, apologies, I think I misread it.
r? @rust-lang/core