Announce Rust 1.92 stable release #1757
Conversation
|
Hi relnotes-interest-group, this PR adds a release blog post. Could you review cc @alex-semenyuk @jieyouxu @joshtriplett @Kobzol @lcnr @traviscross |
| ### Platform Support | ||
|
|
||
| Refer to Rust’s [platform support page][platform-support] for more information on Rust’s tiered platform support. |
There was a problem hiding this comment.
Do we just drop this section when there's no changes to platform support 😆
| CannotFail.method(); // No error | ||
| CanFail.method(); // Error: unused `Result` that must be used |
There was a problem hiding this comment.
| CannotFail.method(); // No error | |
| CanFail.method(); // Error: unused `Result` that must be used | |
| CannotFail.method(); // No warning | |
| CanFail.method(); // Warning: unused `Result` that must be used |
Those are warnings, not errors, right?
|
|
||
| ### Restrictions on user code impls of `DerefMut` for `Pin` | ||
|
|
||
| A soundness issue with `Pin` has been solved by preventing third-party crates from implementing `DerefMut` for `Pin<T>` when `T` is a local type that doesn't implement `DerefMut<Target: Unpin>`. |
There was a problem hiding this comment.
This seems a bit hard to grok without context. Maybe at least a PR/issue link would make it clearer?
There was a problem hiding this comment.
I suspect we can just delete this item.
|
|
||
| ### Validate input to `#[macro_export]` | ||
|
|
||
| Over the past few releases, many changes were made to the way built-in attributes are processed in the compiler. This should greatly improve the error messages and warnings rust gives for built-in attributes and especially make these diagnostics more consistent among all of the over 100 built-in attributes. |
There was a problem hiding this comment.
| Over the past few releases, many changes were made to the way built-in attributes are processed in the compiler. This should greatly improve the error messages and warnings rust gives for built-in attributes and especially make these diagnostics more consistent among all of the over 100 built-in attributes. | |
| Over the past few releases, many changes were made to the way built-in attributes are processed in the compiler. This should greatly improve the error messages and warnings Rust gives for built-in attributes and especially make these diagnostics more consistent among all of the over 100 built-in attributes. |
|
|
||
| The language and compiler teams continue to work on stabilization of the [never type](https://doc.rust-lang.org/stable/std/primitive.never.html). In this release the [`never_type_fallback_flowing_into_unsafe`](https://doc.rust-lang.org/beta/rustc/lints/listing/deny-by-default.html#dependency-on-unit-never-type-fallback) and [`dependency_on_unit_never_type_fallback`](https://doc.rust-lang.org/beta/rustc/lints/listing/deny-by-default.html#dependency-on-unit-never-type-fallback) future compatibility lints were made deny-by-default, meaning they will cause a compilation error when detected. | ||
|
|
||
| These lints detect code which is likely to be broken by the never type stabilization. It is highly advised to fix them if they are reported in your crate. |
There was a problem hiding this comment.
I wonder if we should add something about how wide the breakage here is based on crater or something? As is it sounds a bit like "rust is making breaking changes" which while semi-true probably needs caveats for a blog post.
There was a problem hiding this comment.
It's worth mentioning too that 1) a deny-by-default lint only causes an error by default -- it's still a lint, and the lint can be suppressed, and 2) the error only occurs when building the crate that contains the linted-on code, not when building its dependents. (A warning will be reported in the builds of the dependents, when using Cargo.)
| } | ||
|
|
||
| fn main() { | ||
| can_never_fail() |
There was a problem hiding this comment.
This doesn't type check, right? You still need a ; here?
|
|
||
| ### Restrictions on user code impls of `DerefMut` for `Pin` | ||
|
|
||
| A soundness issue with `Pin` has been solved by preventing third-party crates from implementing `DerefMut` for `Pin<T>` when `T` is a local type that doesn't implement `DerefMut<Target: Unpin>`. |
There was a problem hiding this comment.
I suspect we can just delete this item.
7 participants
Draft release notes - rust-lang/rust#149161
@rustbot ping relnotes-interest-group
Rendered