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

Centri3

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

@Centri3

@rustbot

r? @WaffleLapkin

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

@rustbot 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

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 ojeda mentioned this pull request

Jul 29, 2023

46 tasks

@Centri3

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

This is T-lang and not T-compiler.

Noratrieb

@WaffleLapkin

@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 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

@joshtriplett

@rfcbot

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

Concerns:

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

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

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

@RalfJung

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

@RalfJung

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

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

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

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

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

With FCP being complete,
@bors r+

@bors

📌 Commit 1f7bad0 has been approved by WaffleLapkin

It is now in the queue for this repository.

@bors 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

@bors

@rust-timer

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 Centri3 deleted the explicit-repr-rust branch

August 25, 2023 17:16

@ojeda ojeda mentioned this pull request

Dec 10, 2023

42 tasks

intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request

Dec 14, 2023

@ojeda @intel-lab-lkp

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

Dec 14, 2023

@ojeda @fbq

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

Dec 18, 2023

@ojeda @UtsavBalar1231

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

Dec 21, 2023

@ojeda

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

Jan 8, 2024

@he32

Pkgsrc changes:

Upstream changes:

Version 1.74.1 (2023-12-07)

Version 1.74.0 (2023-11-16)

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

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

Aug 22, 2024

@bors

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

Sep 18, 2024

@workingjubilee

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

Sep 18, 2024

@workingjubilee

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

Sep 19, 2024

@rust-timer

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

disposition-merge

This issue / PR is in PFCP or FCP with a disposition to merge it.

finished-final-comment-period

The final comment period is finished for this PR / Issue.

merged-by-bors

This PR was explicitly merged by bors.

S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

S-waiting-on-fcp

Status: PR is in FCP and is awaiting for FCP to complete.

T-lang

Relevant to the language team, which will review and decide on the PR/issue.