Skip to content
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

Rust 1.30 #281

Merged
merged 6 commits into from
Oct 25, 2018
Merged

Rust 1.30 #281

merged 6 commits into from
Oct 25, 2018

Conversation

steveklabnik
Copy link
Member

r? @rust-lang/core

@ashleygwilliams will be making me a GIF to include in the post tonight or tomorrow, but we can't forget that before a merge.

its rules felt awkward in practice. These changes are the first steps we're
taking to make the module system feel more straightforward.

[`mod.rs` files are now optional][optionalmod]. Imagine we had a `foo`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is un-stabilized again in rust-lang/rust#55315 due to issues.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can mention tool attributes instead (like #[rustfmt::skip]), they are well hidden in https://github.com/rust-lang/rust/blob/master/RELEASES.md#misc in the release notes.

Copy link
Member

@jtgeibel jtgeibel Oct 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, I've just opened up rust-lang/rust#55331. The tool_lints feature doesn't actually land until 1.31, even though the compiler warns and recommends the new syntax.

Edit: I've confirmed that 1.30 doesn't actually generate a warning on this when running cargo clippy. It looks like this was backed out of beta some time ago rust-lang/rust@27daef9.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jtgeibel
The release notes talk about tool attributes (#[rustfmt::skip]) rather than tool lints (#[allow(clippy::something)]).
Tool attributes were indeed stabilized on 1.30.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@petrochenkov thanks a lot for the clarification, I wasn't aware those were separate. If it is added to the blog post it may be worth clarifying the distinction because I could see others being confused as well.

its rules felt awkward in practice. These changes are the first steps we're
taking to make the module system feel more straightforward.

[`mod.rs` files are now optional][optionalmod]. Imagine we had a `foo`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is being dropped from the release (last minute bug found)


// new
let json = serde_json::from_str("...");
```
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't demonstrate use but the text indicates it should?


There's two changes to `use` as well. Well, three changes: we already
mentioned that you can use `use` to bring macros into scope in the macros
section. There's two more. The first is that you can [`use` an extern crate
Copy link
Contributor

@petrochenkov petrochenkov Oct 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This not about use, this is about anything but use actually.
What happens is that extern crate names are put into prelude, so in relative paths they can be used from the whole crate without importing, similarly to e.g. Vec or Copy.
(Paths in use are absolute on 2015 edition, so they are not affected by this change.)

@CryZe
Copy link
Contributor

CryZe commented Oct 24, 2018

I feel like the fact that libcore can be used on stable now deserves its own section (panic handling being unstable made it impossible to use stable for any actual libcore only binaries or libraries before). This is huge for embedded.

@pietroalbini
Copy link
Member

cc @rust-lang/release

The largest feature of Cargo in this release is that we now [have a progress
bar!](https://github.com/rust-lang/cargo/pull/5995/)

> GIF goes here
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a reminder to put the gif here (or maybe asciinema?).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a GIF is nicer as it starts automatically, so it is more eye-catching.

@carols10cents
Copy link
Member

I just pushed some changes without seeing the other comments-- I was confused by the use section as well and I tried to clarify but I'm not sure if I succeeded.

PLEASE check my work and back out anything that's wrong ❤️

@dtolnay
Copy link
Member

dtolnay commented Oct 25, 2018

As part of the procedural macro stabilizations, it would be good to call out that span information on errors in generated code are transparently getting way better. For example in Serde derives (notice where the span points to):

#[derive(Serialize)]
struct Demo {
    ok: String,
    bad: std::thread::Thread,
}

Before

error[E0277]: the trait bound `std::thread::Thread: _IMPL_SERIALIZE_FOR_Demo::_serde::Serialize` is not satisfied
 --> src/main.rs:3:10
  |
3 | #[derive(Serialize)]
  |          ^^^^^^^^^ the trait `_IMPL_SERIALIZE_FOR_Demo::_serde::Serialize` is not implemented for `std::thread::Thread`

After

error[E0277]: the trait bound `std::thread::Thread: serde::Serialize` is not satisfied
 --> src/main.rs:7:5
  |
7 |     bad: std::thread::Thread,
  |     ^^^ the trait `serde::Serialize` is not implemented for `std::thread::Thread`

The improvement comes automatically with no code changes for macros that are based on syn / quote / proc-macro2.

The libproc_macro stabilizations to enable this actually landed in 1.29 but @alexcrichton had wanted to delay drawing attention to it until the big bang stabilization of procedural macros in 1.30.


See the [detailed release notes][notes] for more.

### Library stabilizations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps it makes sense to mention proc macro API here (https://doc.rust-lang.org/stable/proc_macro/index.html).
It was secretly stabilized in 1.29 and then never announced officially.

structs and enums; attributes can go on other places as well, like functions.
As an example of using an attribute-like macro, you might have something like
this when using a web application framework:
Attribute-like macros are similar to custom derive macros, but instead of generating code
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wording nit: attribute macros are not "-like" attributes, they are attributes.

(While function-like macros are obviously not functions, so the "-like" suffix is justified there.)

imports much less when moving code around.
The old behavior of `use` paths always starting from the crate root still applies. But
after making a one-time switch to the new style, these rules will apply uniformly to
paths everywhere, and you'll need to tweak your imports much less when moving code around.
Copy link
Contributor

@petrochenkov petrochenkov Oct 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what this paragraph is talking about, the changes stabilized in 1.30 neither reduce "import tweaking when moving code around" in any way, nor "lead to a more straightforward understanding of how paths resolve".

All of those are supposed benefits of the 2018 edition module system, that's not stabilized yet and require explicit switching to 2018 edition.
Right now (1.30 / 2015 edition) crate:: in paths is supported to simplify migration to 2018 rather than anything else.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit more constructively:

  • Non-imports starting with a crate name require less tweaking when moving code around due to the "::serde_json::from_str -> serde_json::from_str" change.
  • If crate:: is used consistently in imports (the "still on 2015, but ready for 2018 migration" mode), then we have more straightforward import logic - they always start with a crate name or a special keyword.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i was purely talking about moving code within submodules, not moving to or from 2015/2018, like your first bullet point

@steveklabnik
Copy link
Member Author

Thanks folks, I'm pretty sure I got everything here.

```

Moving a function to a submodule and having your imports break was not a great
experience. Now, `use` will check the first part of the path and see if it's an `extern
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"use will check" -> "relative paths will check"
"imports break" -> "non-imports break" (well, there's probably some better wording for "non-imports")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i tried a better wording, thank you :)

@Mark-Simulacrum Mark-Simulacrum merged commit c784c7d into gh-pages Oct 25, 2018
@Mark-Simulacrum Mark-Simulacrum deleted the 1.30-announcement branch October 25, 2018 16:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants