Skip to content
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.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Disable dead variant removal for #[repr(C)] enums. #123043

Merged
merged 2 commits into from
Jul 4, 2024
Merged

Disable dead variant removal for #[repr(C)] enums. #123043

merged 2 commits into from
Jul 4, 2024

Conversation

GoldsteinE
Copy link
Contributor

@GoldsteinE GoldsteinE commented Mar 25, 2024 •
edited
Loading

This prevents removing dead branches from a #[repr(C)] enum (they now get discriminants allocated as if they were inhabited).

Implementation notes: ABI of something like

#[repr(C)]
enum Foo {
    Foo(!),
}

is still Uninhabited, but its layout is now computed as if all the branches were inhabited.
This seemed to me like a proper way to do it, especially given that ABI sanity check explicitly asserts that type-level uninhabitedness implies ABI uninhabitedness.

This probably needs some sort of FCP (given that it changes #[repr(C)] layout, which is a stable guarantee), but I’m not sure how to call for one or which team is the most relevant.

See rust-lang/unsafe-code-guidelines#500.

@rustbot
Copy link
Collaborator

rustbot commented Mar 25, 2024

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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 Mar 25, 2024
@GoldsteinE
Copy link
Contributor Author

@oli-obk Hi! Could you maybe express your opinion on the test issue (and just look at the PR in general?)

I could write a rustc_layout test for #[repr(C, int)] enums and a @run-pass test for #[repr(C)] enums, it looks like it would cover all the cases.

@oli-obk oli-obk added the I-lang-nominated Nominated for discussion during a lang team meeting. label Apr 23, 2024
@traviscross
Copy link
Contributor

@rustbot labels -I-lang-nominated

We discussed this in the lang call today and we agreed that this is a bug fix. This is OK to move forward.

@rustbot rustbot removed the I-lang-nominated Nominated for discussion during a lang team meeting. label May 1, 2024
@GoldsteinE
Copy link
Contributor Author

I pushed shiny new rustc_layout tests. There are two of them: repr-c-int-dead-variants tests #[repr(C, u8)] and is run for every platform and repr-c-dead-variants runs on four platforms: three major archs plus one ARM target that has interesting c-enum-min-bits (it’s done via --target, not only-, so it should be actually tested in CI).

I also added a line into abi/compatibility.rs that asserts the initial claim: ReprCEnum<Void> should be compatible with ReprCEnum<MaybeUninit<Void>>.

@rust-log-analyzer

This comment has been minimized.

Sign in to view
@GoldsteinE
Copy link
Contributor Author

Ok, apparently u64 has 4-byte align on some targets. I’ll make it less target-dependent.

@rust-log-analyzer

This comment has been minimized.

Sign in to view
@GoldsteinE
Copy link
Contributor Author

That seems spurious. I don’t suppose I have enough rights to retry the pipeline?

@RalfJung
Copy link
Member

RalfJung commented May 5, 2024

We're having some CI trouble currently, this may be related. So I suggest to wait for a few hours.

You can retrigger the pipeline by closing and re-opening the PR.

@GoldsteinE GoldsteinE closed this May 5, 2024
@GoldsteinE GoldsteinE reopened this May 5, 2024
@oli-obk oli-obk added T-lang Relevant to the language team, which will review and decide on the PR/issue. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. I-lang-nominated Nominated for discussion during a lang team meeting. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-lang-nominated Nominated for discussion during a lang team meeting. labels May 24, 2024
@oli-obk
Copy link
Contributor

oli-obk commented May 24, 2024

We discussed this in the lang call today and we agreed that this is a bug fix. This is OK to move forward.

still needs an FCP though, right? Or is that bugfixy enough to just land?

@RalfJung
Copy link
Member

RalfJung commented May 24, 2024 via email

@WaffleLapkin
Copy link
Member

The meeting notes explicitly say no FCP is needed:

TC: What do we think?

NM: This seems like it's not changing the reference, but fixing a bug, in which case I'm in favor. The set of variants that are listed in the enum are about layout.

pnkfelix: I agree.

tmandry: It seems like a bug fix. Sounds good to me.

Consensus: We're OK with this and believe it to be a bug fix. Therefore, no FCP needed and it's OK to go ahead based on our meeting consensus.

(emph mine, ref: https://hackmd.io/@rust-lang-team/rkF1tAkzC#Disable-dead-variant-removal-for-reprC-enums-rust123043)

@WaffleLapkin WaffleLapkin removed the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label May 24, 2024
@oli-obk
Copy link
Contributor

oli-obk commented Jun 28, 2024

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 28, 2024
@GoldsteinE
Copy link
Contributor Author

I removed the word “inhabited”.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 28, 2024
@oli-obk
Copy link
Contributor

oli-obk commented Jul 4, 2024

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jul 4, 2024

📌 Commit 8a3c07a has been approved by oli-obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 4, 2024
@matthiaskrgr matthiaskrgr mentioned this pull request Jul 4, 2024
Merged
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 4, 2024
@bors
Auto merge of rust-lang#127326 - matthiaskrgr:rollup-kz7vd3w, r=matth…
8a9cccb 
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#123043 (Disable dead variant removal for `#[repr(C)]` enums.)
 - rust-lang#126405 (Migrate some rustc_builtin_macros to SessionDiagnostic)
 - rust-lang#127037 (Remove some duplicated tests)
 - rust-lang#127283 (Reject SmartPointer constructions not serving the purpose)
 - rust-lang#127301 (Tweak some structured suggestions to be more verbose and accurate)
 - rust-lang#127307 (Allow to have different types for arguments of `Rustc::remap_path_prefix`)
 - rust-lang#127309 (jsondocck: add `$FILE` built-in variable)
 - rust-lang#127314 (Trivial update on tidy bless note)
 - rust-lang#127319 (Remove a use of `StructuredDiag`, which is incompatible with automatic error tainting and error translations)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit f0a0f8f into rust-lang:master Jul 4, 2024
6 checks passed
@rustbot rustbot added this to the 1.81.0 milestone Jul 4, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jul 4, 2024
@rust-timer
Unrolled build for rust-lang#123043
eea9cd6 
Rollup merge of rust-lang#123043 - GoldsteinE:fix/repr-c-dead-branches, r=oli-obk

Disable dead variant removal for `#[repr(C)]` enums.

This prevents removing dead branches from a `#[repr(C)]` enum (they now get discriminants allocated as if they were inhabited).

Implementation notes: ABI of something like

```rust
#[repr(C)]
enum Foo {
    Foo(!),
}
```

is still `Uninhabited`, but its layout is now computed as if all the branches were inhabited.
This seemed to me like a proper way to do it, especially given that ABI sanity check explicitly asserts that type-level uninhabitedness implies ABI uninhabitedness.

This probably needs some sort of FCP (given that it changes `#[repr(C)]` layout, which is a stable guarantee), but I’m not sure how to call for one or which team is the most relevant.

See rust-lang/unsafe-code-guidelines#500.
@GoldsteinE
Copy link
Contributor Author

Nice, thanks!

Should that be announced in some way? It’s kind of a rare case, but it’s also a subtle change in observable behaviour, so I’m not sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@oli-obk oli-obk oli-obk left review comments

@RalfJung RalfJung RalfJung left review comments

Assignees

@oli-obk oli-obk

Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.81.0
Development

Successfully merging this pull request may close these issues.
8 participants
@GoldsteinE @rustbot @traviscross @rust-log-analyzer @RalfJung @oli-obk @WaffleLapkin @bors