Skip to content

Conversation

GoldsteinE
Copy link
Contributor

@GoldsteinE GoldsteinE commented Mar 25, 2024

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 GoldsteinE force-pushed the fix/repr-c-dead-branches branch from eea0d6a to d34e10c Compare May 4, 2024 21:24
@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.

@GoldsteinE
Copy link
Contributor Author

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

@GoldsteinE GoldsteinE force-pushed the fix/repr-c-dead-branches branch from d34e10c to fa62263 Compare May 4, 2024 22:35
@rust-log-analyzer

This comment has been minimized.

@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 needs-fcp This change is insta-stable, or significant enough to need a team 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, or significant enough to need a team 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 GoldsteinE force-pushed the fix/repr-c-dead-branches branch from d529329 to 8a3c07a Compare June 28, 2024 17:20
@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
Collaborator

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
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 4, 2024
…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
@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
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
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants