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

Add short summaries to all 2021 edition changes. #243

Merged
merged 1 commit into from
Jun 14, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
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
7 changes: 6 additions & 1 deletion src/rust-2021/IntoIterator-for-arrays.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,11 @@

## Summary

- Arrays implement `IntoIterator` in *all* editions.
- The new `.into_iter()` is *hidden* in Rust 2015 and Rust 2018 in method call syntax.
So, `array.into_iter()` still resolves to `(&array).into_iter()` as before.
- `array.into_iter()` changes meaning when switching to Rust 2021.

## Details

Until Rust 1.53, only *references* to arrays implement `IntoIterator`.
Expand Down Expand Up @@ -46,4 +51,4 @@ there is no added complexity in the new edition.

[25]: https://github.com/rust-lang/rust/issues/25725
[20]: https://github.com/rust-lang/rust/pull/65819
[22]: https://doc.rust-lang.org/book/ch05-03-method-syntax.html#wheres-the---operator
[22]: https://doc.rust-lang.org/book/ch05-03-method-syntax.html#wheres-the---operator
4 changes: 3 additions & 1 deletion src/rust-2021/default-cargo-resolver.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,8 @@

## Summary

- `edition = "2021"` implies `resolver = "2"` in `Cargo.toml`.

## Details

Since Rust 1.51.0, Cargo has opt-in support for a [new feature resolver][4]
Expand All @@ -15,4 +17,4 @@ crates that are depended on in multiple ways.
See [the announcement of Rust 1.51][5] for details.

[4]: https://doc.rust-lang.org/cargo/reference/resolver.html#feature-resolver-version-2
[5]: https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#cargos-new-feature-resolver
[5]: https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#cargos-new-feature-resolver
3 changes: 3 additions & 0 deletions src/rust-2021/disjoint-capture-in-closures.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,9 @@

## Summary

- `|| a.x + 1` now captures only `a.x` instead of `a`.
- This can subtly change the drop order of things.

## Details

[Closures](https://doc.rust-lang.org/book/ch13-01-closures.html)
Expand Down
4 changes: 4 additions & 0 deletions src/rust-2021/or-patterns-macro-rules.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,10 @@

## Summary

- `$_:pat` in `macro_rules` now matches `|` too: e.g. `A | B`.
- `$_:pat_param` behaves like `$_:pat` did before; it does not match (top level) `|`.
- `$_:pat_param` is available in all editions.

## Details

Starting in Rust 1.53.0, [patterns](https://doc.rust-lang.org/stable/reference/patterns.html)
Expand Down
8 changes: 6 additions & 2 deletions src/rust-2021/panic-macro-consistency.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,8 +2,12 @@

## Summary

## Details
- `panic!(..)` now always use `format_args!(..)`, just like `println!()`.
- `panic!("{")` is no longer accepted, without escaping the `{` as `{{`.
- `panic!(x)` is no longer accepted if `x` is not a string literal.
- Use `std::panic::panic_any(x)` to panic with a non-string payload.

## Details

The `panic!()` macro is one of Rust's most well known macros.
However, it has [some subtle surprises](https://github.com/rust-lang/rfcs/blob/master/text/3007-panic-plan.md)
Expand Down Expand Up @@ -41,4 +45,4 @@ will be the only way to panic with something other than a formatted string.

In addition, `core::panic!()` and `std::panic!()` will be identical in Rust 2021.
Currently, there are some historical differences between those two,
which can be noticable when switching `#![no_std]` on or off.
which can be noticable when switching `#![no_std]` on or off.
3 changes: 3 additions & 0 deletions src/rust-2021/prelude.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,9 @@

## Summary

- `TryInto`, `TryFrom` and `FromIterator` are now part of the prelude.
- This might change the meaning of e.g. `x.try_into()` depending on types and imports.

## Details

The [prelude of the standard library](https://doc.rust-lang.org/stable/std/prelude/index.html)
Expand Down
6 changes: 5 additions & 1 deletion src/rust-2021/reserving-syntax.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,10 @@

## Summary

- `any_prefix#..`, `any_prefix".."`, and `any_prefix'..'` are reserved syntax, and no longer tokenize.
- These did not parse as valid Rust in any edition, except in arguments to macros.
- Insert whitespace to avoid errors.

## Details

To make space for some new syntax in the future,
Expand Down Expand Up @@ -37,4 +41,4 @@ These are some new prefixes you might see in the future:
this prefix would've allowed us to accept `k#async` in edition 2015
without having to wait for edition 2018 to reserve `async` as a keyword.

[10]: https://github.com/rust-lang/rfcs/pull/3101
[10]: https://github.com/rust-lang/rfcs/pull/3101
4 changes: 3 additions & 1 deletion src/rust-2021/warnings-promoted-to-error.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,8 @@

## Summary

- `bare-trait-objects` and `ellipsis-inclusive-range-patters` are now hard errors.

## Details

Two existing lints are becoming hard errors in Rust 2021.
Expand All @@ -14,4 +16,4 @@ These lints will remain warnings in older editions.
* `ellipsis-inclusive-range-patterns`:
The [deprecated `...` syntax](https://doc.rust-lang.org/stable/reference/patterns.html#range-patterns)
for inclusive range patterns is no longer accepted in Rust 2021.
It has been superseded by `..=`, which is consistent with expressions.
It has been superseded by `..=`, which is consistent with expressions.