add changelog entries for 1.92 release #638
Conversation
tshepang
force-pushed
the
tshepang/changelog
branch
5 times, most recently
from
f5aeb4c to
58c1d46
Compare
tshepang
force-pushed
the
tshepang/changelog
branch
from
58c1d46 to
ab1e5fe
Compare
2061: FLS updates for 26.02 r=Hoverbear a=tshepang rust-lang/fls#638 Co-authored-by: Tshepang Mbambo <tshepang.mbambo@ferrous-systems.com>
2061: FLS updates for 26.02 r=Hoverbear a=tshepang rust-lang/fls#638 Co-authored-by: Tshepang Mbambo <tshepang.mbambo@ferrous-systems.com>
PLeVasseur
left a comment
PLeVasseur
left a comment
There was a problem hiding this comment.
Less "comments on @tshepang's lovely work", more "how should we approach those items which need not be documented due to the FLS not including that level of granularity currently?"
| Language changes in Rust 1.92.0 | ||
| ------------------------------- | ||
|
|
||
| - `Document MaybeUninit representation and validity <https://github.com/rust-lang/rust/pull/140463>`_ |
There was a problem hiding this comment.
Does that mean we should open an issue to document MaybeUninit? Just double-checked and it's in the 2021 edition.
There was a problem hiding this comment.
Per discussion, this is defined in core, therefore not part of the documentation in the Reference, either.
|
|
||
| - This is not a language change | ||
|
|
||
| - `Allow "&raw [mut | const]" for union field in safe code <https://github.com/rust-lang/rust/pull/141469>`_ |
There was a problem hiding this comment.
Does that mean we should open an issue to document unions more comprehensively?
There was a problem hiding this comment.
Per discussion, this did also not imply a Reference update. Bug fix.
|
|
||
| - This is a fix for a regression that only existed in development versions of Rust (Beta and Nightly) | ||
|
|
||
| - `Do not materialize X in "[X; 0]" when X is unsizing a const <https://github.com/rust-lang/rust/pull/145277>`_ |
There was a problem hiding this comment.
Should we open an issue to more comprehensively document this?
Maybe speaks to "how exhaustive" the FLS should be vs can be currently.
There was a problem hiding this comment.
Per discussion, this did also not imply a Reference update. Bug fix.
|
|
||
| - This behavior was not documented in the FLS | ||
|
|
||
| - `Support combining #[track_caller] and #[no_mangle] (requires every declaration specifying #[track_caller] as well) <https://github.com/rust-lang/rust/pull/145724>`_ |
There was a problem hiding this comment.
Should we open an issue to document this? Both #[no_mangle] and #[track_caller] feature in the FLS.
There was a problem hiding this comment.
Per discussion, this did also not imply a Reference update. Bug fix.
|
|
||
| - Lints are not part of the FLS | ||
|
|
||
| - `Allow specifying multiple bounds for same associated item, except in trait objects <https://github.com/rust-lang/rust/pull/146593>`_ |
There was a problem hiding this comment.
Should we open an issue for this? The FLS does document these categories of things.
There was a problem hiding this comment.
Per discussion, this did also not imply a Reference update. This is a lifted restriction which does not imply an FLS update.
We could consider making the Generic Conformance section more detailed.
|
|
||
| - This lifted restriction was not documented in the FLS | ||
|
|
||
| - `Slightly strengthen higher-ranked region handling in coherence <https://github.com/rust-lang/rust/pull/146725>`_ |
There was a problem hiding this comment.
Should we open an issue to document this? Again, goes to "what we can document now" vs "what should probably be documented".
There was a problem hiding this comment.
Per discussion, this did also not imply a Reference update. This is a lifted restriction and would require more granular handling to be relevant. Seems outside the scope of FLS currently.
2 participants
No description provided.