Allow explicit #[repr(Rust)]
by Centri3 · Pull Request #114201 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation31 Commits2 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
This is identical to no repr()
at all. For Rust, packed
and Rust, align(x)
, it should be the same as no Rust
at all (as, afaik, #[repr(align(16))]
uses the Rust ABI.)
The main use case for this is being able to explicitly say "I want to use the Rust ABI" in very very rare circumstances where the first obvious choice would be the C ABI yet is undesirable, which is already possible with functions as extern "Rust"
. This would be useful for silencing rust-lang/rust-clippy#11253. It's also more consistent with extern
.
The lack of this also tripped me up a bit when I was new to Rust, as I expected this to be possible.
workingjubilee, Noratrieb, joshtriplett, dtolnay, Fishrock123, ChayimFriedman2, BD103, izik1, SwannHERRERA, selvmaya, and 3 more reacted with thumbs up emoji WaffleLapkin, selvmaya, vini-fda, WalkerRout, and CGMossa reacted with heart emoji
(rustbot has picked a reviewer for you, use r? to override)
rustbot added S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change itself & the implementation look good to me.
However, this looks like an insta-stable change, so I'll nominate for discussion in T-compiler
meeting. Question for the meeting: does this addition make sense/do we want to add it insta-stably?
ojeda mentioned this pull request
46 tasks
Yeah I didn't put it behind a feature gate as it seems small enough, not really something that'd need further work after the PR that adds it. Also not really something imo that wouldn't want to be supported in the far future. Though if not I'm ok with putting it behind one
This is T-lang and not T-compiler.
@Centri3 to be clear: I don't think this should be behind a feature gate, just don't want to do this decision myself 😅
joshtriplett added T-lang
Relevant to the language team, which will review and decide on the PR/issue.
and removed T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
Concerns:
but-repr-rust-is-free-real-estateresolved by Allow explicit #[repr(Rust)] #114201 (comment)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
We say "a repr(Rust)
struct" in conversations enough that I'm 👍 to allowing that to be literally writable, rather than just an internal convention.
@rfcbot reviewed
rfcbot added the final-comment-period
In the final comment period and will be merged soon unless new substantive objections are raised.
label
🔔 This is now entering its final comment period, as per the review above. 🔔
I remember being honestly surprised when I tried this and it didn't work. 😂
Rust, packed
Isn't currently packed
equivalent to C, packed
? At least that's what it looks like.
Maybe C
and Rust
are equivalent here since there is no benefit from reordering fields.
Is that so? I wasn't entirely sure so I allowed it there.
Even if they're basically equivalent we should change it if packed
isn't Rust, packed
. Though it should probably be confirmed that packed
isn't Rust,
, I'm not particularly able to speak confidently on that ^^
I will test this once I get the chance to with Rust, packed
to see if the output is the same. Though even then we probably have to be careful
Actually though, if packed
is like C, packed
then that may be ok if we document it and test that Rust, packed
works properly (even if fields aren't recorded)
Isn't currently
packed
equivalent toC, packed
? At least that's what it looks like.
That may be the case now but it looks like we don't guarantee it:
Inter-field padding is guaranteed to be the minimum required in order to satisfy each field's (possibly altered) alignment (although note that, on its own, packed does not provide any guarantee about field ordering).
Even if they're basically equivalent we should change it if
packed
isn'tRust, packed
. Though it should probably be confirmed thatpacked
isn'tRust,
, I'm not particularly able to speak confidently on that ^^
Given that we don't make any guarantees about what Rust
layout is, nor do we make any guarantees about the field ordering of packed
, I am okay with packed
changing the field order in a way that happens to agree with C, packed
today. But Rust, packed
should always mean the same thing as just packed
.
Forgive the bikeshed, but I'd like to propose that we reserve repr(Rust)
for a possible non-default stable Rust ABI to be introduced in the future.
Even if you don't think that's a good idea, the reference has a name for what we're calling repr(Rust)
: the "default representation". With that as inspiration I'd propose that we rename to repr(default)
, because that's exactly what it signifies: the default, no-guarantee representation used by the compiler. As a result I think this is actually a better name than repr(Rust)
.
I know people use repr(Rust)
to refer to this today, but if we came up with an alternate spelling I think people would start using that instead. Given that I think repr(default)
is a better name and leaves room to use repr(Rust)
for something officially stable in the future, I'm raising a concern so we can discuss before stabilizing.
@rfcbot concern but-repr-rust-is-free-real-estate
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
This will be merged soon.
With FCP being complete,
@bors r+
📌 Commit 1f7bad0 has been approved by WaffleLapkin
It is now in the queue for this repository.
bors added the S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Finished benchmarking commit (4354192): comparison URL.
Overall result: ✅ improvements - no action needed
@rustbot label: -perf-regression
Instruction count
This is a highly reliable metric that was used to determine the overall result at the top of this comment.
mean | range | count | |
---|---|---|---|
Regressions ❌ (primary) | - | - | 0 |
Regressions ❌ (secondary) | - | - | 0 |
Improvements ✅ (primary) | - | - | 0 |
Improvements ✅ (secondary) | -0.4% | [-0.4%, -0.4%] | 2 |
All ❌✅ (primary) | - | - | 0 |
Max RSS (memory usage)
Results
This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
mean | range | count | |
---|---|---|---|
Regressions ❌ (primary) | - | - | 0 |
Regressions ❌ (secondary) | - | - | 0 |
Improvements ✅ (primary) | -3.6% | [-3.6%, -3.6%] | 1 |
Improvements ✅ (secondary) | -2.9% | [-2.9%, -2.9%] | 1 |
All ❌✅ (primary) | -3.6% | [-3.6%, -3.6%] | 1 |
Cycles
Results
This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
mean | range | count | |
---|---|---|---|
Regressions ❌ (primary) | - | - | 0 |
Regressions ❌ (secondary) | - | - | 0 |
Improvements ✅ (primary) | -0.9% | [-0.9%, -0.9%] | 1 |
Improvements ✅ (secondary) | - | - | 0 |
All ❌✅ (primary) | -0.9% | [-0.9%, -0.9%] | 1 |
Binary size
This benchmark run did not return any relevant results for this metric.
Bootstrap: 629.602s -> 631.442s (0.29%)
Artifact size: 315.61 MiB -> 315.61 MiB (0.00%)
Centri3 deleted the explicit-repr-rust branch
ojeda mentioned this pull request
42 tasks
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request
This is the next upgrade to the Rust toolchain, from 1.73.0 to 1.74.1 (i.e. the latest) [1].
See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
Unstable features
No unstable features (that we use) were stabilized.
Therefore, the only unstable features allowed to be used outside the
kernel
crate are still new_uninit,offset_of
, though other code to
be upstreamed may increase the list (e.g. offset_of
was added recently).
Please see [3] for details.
Other improvements
Rust 1.74.0 allows to use #[repr(Rust)]
explicitly [4], which can be
useful to be explicit about particular cases that would normally use
e.g. the C representation, such as silencing lints like the upcoming
additions we requested [5] to the no_mangle_with_rust_abi
Clippy lint
(which in turn triggered the #[repr(Rust)]
addition).
Rust 1.74.0 includes a fix for one of the false negative cases we reported
in Clippy's disallowed_macros
lint [6] that we would like to use in
the future.
Rust 1.74.1 fixes an ICE that the Apple AGX GPU driver was hitting [7].
Required changes
For this upgrade, no changes were required (i.e. on our side).
alloc
upgrade and reviewing
The vast majority of changes are due to our alloc
fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc
and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc
we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc
Now one may check the new.patch
to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1741-2023-12-07 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux#2 [3] Link: rust-lang/rust#114201 [4] Link: rust-lang/rust-clippy#11219 [5] Link: rust-lang/rust-clippy#11431 [6] Link: rust-lang/rust#117976 (comment) [7] Signed-off-by: Miguel Ojeda ojeda@kernel.org
fbq pushed a commit to Rust-for-Linux/linux that referenced this pull request
This is the next upgrade to the Rust toolchain, from 1.73.0 to 1.74.1 (i.e. the latest) [1].
See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
Unstable features
No unstable features (that we use) were stabilized.
Therefore, the only unstable features allowed to be used outside the
kernel
crate are still new_uninit,offset_of
, though other code to
be upstreamed may increase the list (e.g. offset_of
was added recently).
Please see [3] for details.
Other improvements
Rust 1.74.0 allows to use #[repr(Rust)]
explicitly [4], which can be
useful to be explicit about particular cases that would normally use
e.g. the C representation, such as silencing lints like the upcoming
additions we requested [5] to the no_mangle_with_rust_abi
Clippy lint
(which in turn triggered the #[repr(Rust)]
addition).
Rust 1.74.0 includes a fix for one of the false negative cases we reported
in Clippy's disallowed_macros
lint [6] that we would like to use in
the future.
Rust 1.74.1 fixes an ICE that the Apple AGX GPU driver was hitting [7].
Required changes
For this upgrade, no changes were required (i.e. on our side).
alloc
upgrade and reviewing
The vast majority of changes are due to our alloc
fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc
and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc
we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc
Now one may check the new.patch
to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1741-2023-12-07 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: #2 [3] Link: rust-lang/rust#114201 [4] Link: rust-lang/rust-clippy#11219 [5] Link: rust-lang/rust-clippy#11431 [6] Link: rust-lang/rust#117976 (comment) [7] Signed-off-by: Miguel Ojeda ojeda@kernel.org Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Link: https://lore.kernel.org/r/20231214092958.377061-1-ojeda@kernel.org
UtsavBalar1231 pushed a commit to UtsavBalar1231/kernel_rockchip_linux that referenced this pull request
This is the next upgrade to the Rust toolchain, from 1.73.0 to 1.74.1 (i.e. the latest) [1].
See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
Unstable features
No unstable features (that we use) were stabilized.
Therefore, the only unstable features allowed to be used outside the
kernel
crate are still new_uninit,offset_of
, though other code to
be upstreamed may increase the list (e.g. offset_of
was added recently).
Please see [3] for details.
Other improvements
Rust 1.74.0 allows to use #[repr(Rust)]
explicitly [4], which can be
useful to be explicit about particular cases that would normally use
e.g. the C representation, such as silencing lints like the upcoming
additions we requested [5] to the no_mangle_with_rust_abi
Clippy lint
(which in turn triggered the #[repr(Rust)]
addition).
Rust 1.74.0 includes a fix for one of the false negative cases we reported
in Clippy's disallowed_macros
lint [6] that we would like to use in
the future.
Rust 1.74.1 fixes an ICE that the Apple AGX GPU driver was hitting [7].
Required changes
For this upgrade, no changes were required (i.e. on our side).
alloc
upgrade and reviewing
The vast majority of changes are due to our alloc
fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc
and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc
we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc
Now one may check the new.patch
to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1741-2023-12-07 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Link: rust-lang/rust#114201 [4] Link: rust-lang/rust-clippy#11219 [5] Link: rust-lang/rust-clippy#11431 [6] Link: rust-lang/rust#117976 (comment) [7] Signed-off-by: Miguel Ojeda ojeda@kernel.org Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Link: https://lore.kernel.org/r/20231214092958.377061-1-ojeda@kernel.org
ojeda added a commit to ojeda/linux that referenced this pull request
This is the next upgrade to the Rust toolchain, from 1.73.0 to 1.74.1 (i.e. the latest) [1].
See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").
Unstable features
No unstable features (that we use) were stabilized.
Therefore, the only unstable features allowed to be used outside the
kernel
crate are still new_uninit,offset_of
, though other code to
be upstreamed may increase the list (e.g. offset_of
was added recently).
Please see [3] for details.
Other improvements
Rust 1.74.0 allows to use #[repr(Rust)]
explicitly [4], which can be
useful to be explicit about particular cases that would normally use
e.g. the C representation, such as silencing lints like the upcoming
additions we requested [5] to the no_mangle_with_rust_abi
Clippy lint
(which in turn triggered the #[repr(Rust)]
addition).
Rust 1.74.0 includes a fix for one of the false negative cases we reported
in Clippy's disallowed_macros
lint [6] that we would like to use in
the future.
Rust 1.74.1 fixes an ICE that the Apple AGX GPU driver was hitting [7].
Required changes
For this upgrade, no changes were required (i.e. on our side).
alloc
upgrade and reviewing
The vast majority of changes are due to our alloc
fork being upgraded
at once.
There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.
Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream alloc
and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.
Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.
To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of alloc
we use) before and after
applying this patch:
# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc
# Apply this patch.
git -C linux am rust-upgrade.patch
# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc
Now one may check the new.patch
to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.
Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1741-2023-12-07 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux#2 [3] Link: rust-lang/rust#114201 [4] Link: rust-lang/rust-clippy#11219 [5] Link: rust-lang/rust-clippy#11431 [6] Link: rust-lang/rust#117976 (comment) [7] Reviewed-by: Martin Rodriguez Reboredo yakoyoku@gmail.com Reviewed-by: Alice Ryhl aliceryhl@google.com Reviewed-by: Benno Lossin benno.lossin@proton.me Tested-by: David Gow davidgow@google.com Link: https://lore.kernel.org/r/20231214092958.377061-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda ojeda@kernel.org
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request
Pkgsrc changes:
- Remove NetBSD-8 support (embedded LLVm requires newer C++ than what is in -8; it's conceivable that this could still build with an external LLVM)
- undo powerpc 9.0 file naming tweak, since we no longer support -8.
- Remove patch to LLVM for powerpc now included by upstream.
- Minor adjustments, checksum changes etc.
Upstream changes:
Version 1.74.1 (2023-12-07)
- [Resolved spurious STATUS_ACCESS_VIOLATIONs in LLVM] (rust-lang/rust#118464)
- [Clarify guarantees for std::mem::discriminant] (rust-lang/rust#118006)
- [Fix some subtyping-related regressions] (rust-lang/rust#116415)
Version 1.74.0 (2023-11-16)
Language
- [Codify that
std::mem::Discriminant<T>
does not depend on any lifetimes in T] (rust-lang/rust#104299) - [Replace
private_in_public
lint withprivate_interfaces
andprivate_bounds
per RFC 2145] (rust-lang/rust#113126) Read more in RFC 2145. - [Allow explicit
#[repr(Rust)]
] (rust-lang/rust#114201) - [closure field capturing: don't depend on alignment of packed fields] (rust-lang/rust#115315)
- [Enable MIR-based drop-tracking for
async
blocks] (rust-lang/rust#107421)
Compiler
- [stabilize combining +bundle and +whole-archive link modifiers] (rust-lang/rust#113301)
- [Stabilize
PATH
option for--print KIND=PATH
] (rust-lang/rust#114183) - [Enable ASAN/LSAN/TSAN for
*-apple-ios-macabi
] (rust-lang/rust#115644) - [Promote loongarch64-unknown-none* to Tier 2] (rust-lang/rust#115368)
- [Add
i686-pc-windows-gnullvm
as a tier 3 target] (rust-lang/rust#115687)
Libraries
- [Implement
From<OwnedFd/Handle>
for ChildStdin/out/err] (rust-lang/rust#98704) - [Implement
From<{&,&mut} [T; N]>
forVec<T>
whereT: Clone
] (rust-lang/rust#111278) - [impl Step for IP addresses] (rust-lang/rust#113748)
- [Implement
From<[T; N]>
forRc<[T]>
andArc<[T]>
] (rust-lang/rust#114041) - [
impl TryFrom<char> for u16
] (rust-lang/rust#114065) - [Stabilize
io_error_other
feature] (rust-lang/rust#115453) - [Stabilize the
Saturating
type] (rust-lang/rust#115477) - [Stabilize const_transmute_copy] (rust-lang/rust#115520)
Stabilized APIs
- [
core::num::Saturating
] (https://doc.rust-lang.org/stable/std/num/struct.Saturating.html) - [
impl From<io::Stdout> for std::process::Stdio
] (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStdout%3E-for-Stdio) - [
impl From<io::Stderr> for std::process::Stdio
] (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStderr%3E-for-Stdio) - [
impl From<OwnedHandle> for std::process::Child{Stdin, Stdout, Stderr}
] (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStderr%3E-for-Stdio) - [
impl From<OwnedFd> for std::process::Child{Stdin, Stdout, Stderr}
] (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStderr%3E-for-Stdio) - [
std::ffi::OsString::from_encoded_bytes_unchecked
] (https://doc.rust-lang.org/stable/std/ffi/struct.OsString.html#method.from_encoded_bytes_unchecked) - [
std::ffi::OsString::into_encoded_bytes
] (https://doc.rust-lang.org/stable/std/ffi/struct.OsString.html#method.into_encoded_bytes) - [
std::ffi::OsStr::from_encoded_bytes_unchecked
] (https://doc.rust-lang.org/stable/std/ffi/struct.OsStr.html#method.from_encoded_bytes_unchecked) - [
std::ffi::OsStr::as_encoded_bytes
] (https://doc.rust-lang.org/stable/std/ffi/struct.OsStr.html#method.as_encoded_bytes) - [
std::io::Error::other
] (https://doc.rust-lang.org/stable/std/io/struct.Error.html#method.other) - [
impl TryFrom<char> for u16
] (https://doc.rust-lang.org/stable/std/primitive.u16.html#impl-TryFrom%3Cchar%3E-for-u16) - [
impl<T: Clone, const N: usize> From<&[T; N]> for Vec<T>
] (https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#impl-From%3C%26%5BT;+N%5D%3E-for-Vec%3CT,+Global%3E) - [
impl<T: Clone, const N: usize> From<&mut [T; N]> for Vec<T>
] (https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#impl-From%3C%26mut+%5BT;+N%5D%3E-for-Vec%3CT,+Global%3E) - [
impl<T, const N: usize> From<[T; N]> for Arc<[T]>
] (https://doc.rust-lang.org/stable/std/sync/struct.Arc.html#impl-From%3C%5BT;+N%5D%3E-for-Arc%3C%5BT%5D,+Global%3E) - [
impl<T, const N: usize> From<[T; N]> for Rc<[T]>
] (https://doc.rust-lang.org/stable/std/rc/struct.Rc.html#impl-From%3C%5BT;+N%5D%3E-for-Rc%3C%5BT%5D,+Global%3E)
These APIs are now stable in const contexts:
- [
core::mem::transmute_copy
] (https://doc.rust-lang.org/beta/std/mem/fn.transmute_copy.html) - [
str::is_ascii
] (https://doc.rust-lang.org/beta/std/primitive.str.html#method.is_ascii) - [
[u8]::is_ascii
] (https://doc.rust-lang.org/beta/std/primitive.slice.html#method.is_ascii)
Cargo
- [fix: Set MSRV for internal packages] (rust-lang/cargo#12381)
- [config: merge lists in precedence order] (rust-lang/cargo#12515)
- [fix(update): Clarify meaning of --aggressive as --recursive] (rust-lang/cargo#12544)
- [fix(update): Make
-p
more convenient by being positional] (rust-lang/cargo#12545) - [feat(help): Add styling to help output ] (rust-lang/cargo#12578)
- [feat(pkgid): Allow incomplete versions when unambigious] (rust-lang/cargo#12614)
- [feat: stabilize credential-process and registry-auth] (rust-lang/cargo#12649)
- [feat(cli): Add '-n' to dry-run] (rust-lang/cargo#12660)
- [Add support for
target.'cfg(..)'.linker
] (rust-lang/cargo#12535) - [Stabilize
--keep-going
] (rust-lang/cargo#12568) - [feat: Stabilize lints] (rust-lang/cargo#12648)
Rustdoc
- [Add warning block support in rustdoc] (rust-lang/rust#106561)
- [Accept additional user-defined syntax classes in fenced code blocks] (rust-lang/rust#110800)
- [rustdoc-search: add support for type parameters] (rust-lang/rust#112725)
- [rustdoc: show inner enum and struct in type definition for concrete type] (rust-lang/rust#114855)
Compatibility Notes
- [Raise minimum supported Apple OS versions] (rust-lang/rust#104385)
- [make Cell::swap panic if the Cells partially overlap] (rust-lang/rust#114795)
- [Reject invalid crate names in
--extern
] (rust-lang/rust#116001) - [Don't resolve generic impls that may be shadowed by dyn built-in impls] (rust-lang/rust#114941)
Internal Changes
These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.
None this cycle.
bors added a commit to rust-lang-ci/rust that referenced this pull request
Gate repr(Rust)
correctly on non-ADT items
rust-lang#114201 added repr(Rust)
but didn't add any attribute validation to it like repr(C)
has, to only allow it on ADT items.
I consider this code to be nonsense, for example:
#[repr(Rust)]
fn foo() {}
Reminder that it's different from extern "Rust"
, which is valid on function items. But also this now disallows repr(Rust)
on modules, impls, traits, etc.
I'll crater it, if it looks bad then I'll add an FCW.
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request
Gate repr(Rust)
correctly on non-ADT items
rust-lang#114201 added repr(Rust)
but didn't add any attribute validation to it like repr(C)
has, to only allow it on ADT items.
I consider this code to be nonsense, for example:
#[repr(Rust)]
fn foo() {}
Reminder that it's different from extern "Rust"
, which is valid on function items. But also this now disallows repr(Rust)
on modules, impls, traits, etc.
I'll crater it, if it looks bad then I'll add an FCW.
https://github.com/rust-lang/rust/labels/relnotes: Compatibility (minor breaking change).
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request
Gate repr(Rust)
correctly on non-ADT items
rust-lang#114201 added repr(Rust)
but didn't add any attribute validation to it like repr(C)
has, to only allow it on ADT items.
I consider this code to be nonsense, for example:
#[repr(Rust)]
fn foo() {}
Reminder that it's different from extern "Rust"
, which is valid on function items. But also this now disallows repr(Rust)
on modules, impls, traits, etc.
I'll crater it, if it looks bad then I'll add an FCW.
https://github.com/rust-lang/rust/labels/relnotes: Compatibility (minor breaking change).
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#129422 - compiler-errors:repr-rust, r=fmease
Gate repr(Rust)
correctly on non-ADT items
rust-lang#114201 added repr(Rust)
but didn't add any attribute validation to it like repr(C)
has, to only allow it on ADT items.
I consider this code to be nonsense, for example:
#[repr(Rust)]
fn foo() {}
Reminder that it's different from extern "Rust"
, which is valid on function items. But also this now disallows repr(Rust)
on modules, impls, traits, etc.
I'll crater it, if it looks bad then I'll add an FCW.
https://github.com/rust-lang/rust/labels/relnotes: Compatibility (minor breaking change).
Labels
This issue / PR is in PFCP or FCP with a disposition to merge it.
The final comment period is finished for this PR / Issue.
This PR was explicitly merged by bors.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Status: PR is in FCP and is awaiting for FCP to complete.
Relevant to the language team, which will review and decide on the PR/issue.