Allow explicit `#[repr(Rust)]` #114201

Centri3 · 2023-07-29T07:00:56Z

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.

rustbot · 2023-07-29T07:01:01Z

r? @WaffleLapkin

(rustbot has picked a reviewer for you, use r? to override)

WaffleLapkin

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?

Centri3 · 2023-07-29T12:23:30Z

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

Noratrieb · 2023-07-29T12:28:04Z

This is T-lang and not T-compiler.

compiler/rustc_passes/messages.ftl

WaffleLapkin · 2023-07-29T13:59:51Z

@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 · 2023-08-01T18:20:59Z

@rfcbot merge

rfcbot · 2023-08-01T18:21:00Z

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-estate~~ resolved 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.

scottmcm · 2023-08-01T18:22:45Z

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 · 2023-08-01T18:26:28Z

🔔 This is now entering its final comment period, as per the review above. 🔔

RalfJung · 2023-08-01T20:02:44Z

I remember being honestly surprised when I tried this and it didn't work. 😂

RalfJung · 2023-08-01T20:04:13Z

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.

Centri3 · 2023-08-01T21:00:37Z

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)

tmandry · 2023-08-08T19:32:37Z

Isn't currently packed equivalent to C, 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't Rust, packed. Though it should probably be confirmed that packed isn't Rust,, 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.

tmandry · 2023-08-08T19:42:02Z

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

rfcbot · 2023-08-24T16:38:51Z

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.

WaffleLapkin · 2023-08-24T20:09:54Z

With FCP being complete,
@bors r+

bors · 2023-08-24T20:09:57Z

📌 Commit 1f7bad0 has been approved by WaffleLapkin

It is now in the queue for this repository.

bors · 2023-08-25T00:02:57Z

⌛ Testing commit 1f7bad0 with merge 4354192...

bors · 2023-08-25T01:43:59Z

☀️ Test successful - checks-actions
Approved by: WaffleLapkin
Pushing 4354192 to master...

rust-timer · 2023-08-25T05:39:19Z

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%)

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>

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

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

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>

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 with `private_interfaces` and `private_bounds` per RFC 2145] (rust-lang/rust#113126) Read more in [RFC 2145](https://rust-lang.github.io/rfcs/2145-type-privacy.html). - [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]>` for `Vec<T>` where `T: Clone`] (rust-lang/rust#111278) - [impl Step for IP addresses] (rust-lang/rust#113748) - [Implement `From<[T; N]>` for `Rc<[T]>` and `Arc<[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.

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.

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).

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).

Allow explicit #[repr(Rust)]

f42d361

rustbot assigned WaffleLapkin Jul 29, 2023

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 29, 2023

WaffleLapkin approved these changes Jul 29, 2023

View reviewed changes

WaffleLapkin added the I-compiler-nominated Nominated for discussion during a compiler team meeting. label Jul 29, 2023

ojeda mentioned this pull request Jul 29, 2023

Clippy wanted features & bugfixes Rust-for-Linux/linux#349

Open

33 tasks

Noratrieb added I-lang-nominated Nominated for discussion during a lang team meeting. and removed I-compiler-nominated Nominated for discussion during a compiler team meeting. labels Jul 29, 2023

Noratrieb reviewed Jul 29, 2023

View reviewed changes

compiler/rustc_passes/messages.ftl Outdated Show resolved Hide resolved

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 Aug 1, 2023

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Aug 1, 2023

rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Aug 1, 2023

rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Aug 1, 2023

joshtriplett removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Aug 8, 2023

joshtriplett added S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 22, 2023

bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Aug 24, 2023

bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 25, 2023

bors merged commit 4354192 into rust-lang:master Aug 25, 2023
11 checks passed

rustbot added this to the 1.74.0 milestone Aug 25, 2023

Centri3 deleted the explicit-repr-rust branch August 25, 2023 17:16

apiraino removed the to-announce Announce this issue on triage meeting label Sep 1, 2023

fmease mentioned this pull request Oct 17, 2023

Make #[repr(Rust)] incompatible with other (non-modifier) representation hints like C and simd #116829

Merged

matthiaskrgr mentioned this pull request Nov 27, 2023

ICE: unrecognized representation hint #118334

Closed

ojeda mentioned this pull request Dec 10, 2023

Rust wanted features Rust-for-Linux/linux#354

Open

39 tasks

compiler-errors mentioned this pull request Aug 22, 2024

Gate repr(Rust) correctly on non-ADT items #129422

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow explicit `#[repr(Rust)]` #114201

Allow explicit `#[repr(Rust)]` #114201

Centri3 commented Jul 29, 2023 •

edited

Loading

rustbot commented Jul 29, 2023

WaffleLapkin left a comment

Centri3 commented Jul 29, 2023 •

edited

Loading

Noratrieb commented Jul 29, 2023

WaffleLapkin commented Jul 29, 2023

joshtriplett commented Aug 1, 2023

rfcbot commented Aug 1, 2023 •

edited

Loading

scottmcm commented Aug 1, 2023

rfcbot commented Aug 1, 2023

RalfJung commented Aug 1, 2023

RalfJung commented Aug 1, 2023 •

edited

Loading

Centri3 commented Aug 1, 2023 •

edited

Loading

tmandry commented Aug 8, 2023 •

edited

Loading

tmandry commented Aug 8, 2023

rfcbot commented Aug 24, 2023

WaffleLapkin commented Aug 24, 2023

bors commented Aug 24, 2023

bors commented Aug 25, 2023

bors commented Aug 25, 2023

rust-timer commented Aug 25, 2023

Allow explicit #[repr(Rust)] #114201

Allow explicit #[repr(Rust)] #114201

Conversation

Centri3 commented Jul 29, 2023 • edited Loading

rustbot commented Jul 29, 2023

WaffleLapkin left a comment

Choose a reason for hiding this comment

Centri3 commented Jul 29, 2023 • edited Loading

Noratrieb commented Jul 29, 2023

WaffleLapkin commented Jul 29, 2023

joshtriplett commented Aug 1, 2023

rfcbot commented Aug 1, 2023 • edited Loading

scottmcm commented Aug 1, 2023

rfcbot commented Aug 1, 2023

RalfJung commented Aug 1, 2023

RalfJung commented Aug 1, 2023 • edited Loading

Centri3 commented Aug 1, 2023 • edited Loading

tmandry commented Aug 8, 2023 • edited Loading

tmandry commented Aug 8, 2023

rfcbot commented Aug 24, 2023

WaffleLapkin commented Aug 24, 2023

bors commented Aug 24, 2023

bors commented Aug 25, 2023

bors commented Aug 25, 2023

rust-timer commented Aug 25, 2023

Overall result: ✅ improvements - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Allow explicit `#[repr(Rust)]` #114201

Allow explicit `#[repr(Rust)]` #114201

Centri3 commented Jul 29, 2023 •

edited

Loading

Centri3 commented Jul 29, 2023 •

edited

Loading

rfcbot commented Aug 1, 2023 •

edited

Loading

RalfJung commented Aug 1, 2023 •

edited

Loading

Centri3 commented Aug 1, 2023 •

edited

Loading

tmandry commented Aug 8, 2023 •

edited

Loading