"Conflicting representations" warning became an error

[Manishearth]

#[repr(u32)]
#[repr(C)]
enum X {
    A, B, C
}

(playground)

This used to be a warning but now is a hard error. This is a breaking change.

This was introduced in 2c3e5d3#diff-9e711d5c109e022cbb94049be8c4ca17 , cc @Centril

[Centril]

I was originally going to turn this into a lint (#67770 (comment)), but @petrochenkov said we always intended to make this an error. Given that it has been a hard-coded warning for so long (3.5 years), it's probable that crater wouldn't show up many instances, but beta crater runs might show otherwise.

[Manishearth]

We just hit this in the wild, this isn't an uncommon mistake to make since typical FFI advice is to slap repr(C) on everything (otherwise the lint yells at you). Also, crates don't necessarily get updated that often, the one that broke for us is two years old. I'll work on getting it updated, but I suspect this will trigger in other stuff.

We should really really not be making breaking changes like these just off the cuff, especially without a future incompatibility lint, and especially rolled into the depths of some basically unrelated refactoring PR. We have a process for this, and there's a reason behind that process -- we have pretty strong stability commitments.

[Centril]

We should really really not be making breaking changes like these just off the cuff, especially without a future incompatibility lint, and especially rolled into the depths of some basically unrelated refactoring PR.

While it's a "breaking change" in the literal sense of "a change that breaks code" it is also a bug-fix for which a hard-coded warning (which are firmer than lints) has existed for a long time. Our policy around bug-fixes makes no hard requirements that we must have C-future-compatibility lints, that crater must be run, and that fixes cannot be landed immediately. These are made, historically, and contemporarily, based on an assessment of the individual case. That is, we have landed such hard errors immediately before and waited for the beta crater run to point out problems.

[Manishearth]

I don't really want to language lawyer the RFC, but since you bring it up, it says:

The first step then is to evaluate the impact of the fix on the crates found in the crates.io website (using e.g. the crater tool). If impact is found to be "small" (which this RFC does not attempt to precisely define), then the fix can simply be landed
.....
As today, the commit message of any breaking change should include the term [breaking-change] along with a description of how to resolve the problem, which helps those people who are affected to migrate their code. A description of the problem should also appear in the relevant subteam report.

The policy definitely says that we should run crater before knowingly landing breakages. Of course, things can be missed and that's what the beta run is for, but in this case it's pretty clear y'all knew it was a breakage.

The PR body did not even mention this breaking change or that changes of this type were being made, let alone call it out as a breaking change so that others may notice it.

We should be immediately reverting this change, and making a second PR with just this change, the appropriate tags being added, the appropriate discussion happening, and a full crater run being done.

Especially since we already have at least one in-use crate affected by this.

---

It's also very clear from this text that the RFC focuses primarily on soundness change, with bugs included but being something that needs more per-case judgement. This bug seems rather benign: it doesn't really do anything unexpected (and definitely not something UBish) if you write #[repr(C, u32)] (since you can't do repr(u32) in C directly to match it), it just doesn't really make sense.

cc @nikomatsakis about the intent of the RFC around more benign compiler bugs.

---

I'm hoping we land rust-lang/rfcs#2834 so that the UX around this gets better as well. Three years is a long time for a crate you maintain, but for "finished" crates (like the googlevr bindings crate that we're using) that are only used as dependencies, it's not really a long time at all.

[nikomatsakis]

My memory is the "intent" of the RFC applied equally to any sort of breaking change. The assumption is that all breaking changes are justified to begin with, so it's only a question of how we go about it. The high-level idea of the RFC is "gently". :)

My position on these sorts of disputes is that if people are complaining, we should typically start by backing out or reversing the "breaking part" of the change, so that we can have the conversation in a "calmer state". As I've said before, my belief is that we can generally get by with less process so long as we're willing to be reasonable when breakage does occur.

That said, I don't feel like I know the particulars of this case. A few questions:

• The problem is multiple repr attributes applied to the same type? (Are there any special cases, e.g., if the same repr is applied multiple times?)
• We currently issue a warning? What exactly does the warning say? Is it a future-compatibility warning, with an associated tracking issue or whatever?
• What was the semantics of multiple repr attributes before the change?
• (Presumably the effect afterwards is to produce an error.)

[nikomatsakis]

I guess I will say this. I don't remember the history of this change, and I wouldn't necessarily want to single it out, but it seems to be an example of a change that isn't really necessary -- making this improvement doesn't fix any soundness hole or have any large effect. Changes of that sort make me nervous, though we do them from time to time for sure.

[petrochenkov]

This can always be changed to a deny-by-default compatibility lint if there's breakage in practice.

I do think this is something that need to be fixed because the compiler just cannot satisfy requests like #[repr(u8, u16)] and the actual codegen in that case is unpredictable.

[Manishearth]

There are some cases in this lint where it's unpredictable, but other cases like repr(C, u32) are less problematic (and thus more common as well). #[repr(C, u32)] is something I can easily imagine someone doing because our advice (and our lints!) advise you to tag everything going through the C ABI as repr(C). Sometimes you're actually passing something as a u32, so you need that repr instead. #[repr(u8, u16)] is nonsensical.

There are definitely cases where this error is a lot more important to make happen, but given the care we take in making breaking changes, it seems broader than necessary in that case, and if there is a breaking change here that needs to happen as soon as possible we should make just that change and not the broader change. I think making the broader change is fine as well, but we could make it with a more relaxed timeline, perhaps waiting for rust-lang/rfcs#2834 or maybe an edition. It's not that pressing.

[Manishearth]

The problem is multiple repr attributes applied to the same type? (Are there any special cases, e.g., if the same repr is applied multiple times?)

Yes. It's for specific mixes only:

• multiple integer types
• simd + c
• C + integer, on a C-like enum

In fact, the following is allowed, because of RFC 2195

#[repr(C, u32)]
enum X {
    A, B, C(bool)
}

We currently issue a warning? What exactly does the warning say? Is it a future-compatibility warning, with an associated tracking issue or whatever?

Yes, but it's a normal hardcoded (non-lint) warning.

What was the semantics of multiple repr attributes before the change?

I believe it's unpredictable for some repr attribute combinations, for others it just ignores one or more.

[petrochenkov]

If something is reasonable to write and the compiler can codegen it, e.g. #[repr(C, u32)] enum Foo (with enum class Foo: uint32_t on the other side of FFI), then it's not "conflicting" and it needs to be allowed and not reported as a warning (previously), or error (now), or a lint.

[Manishearth]

Oh, yeah, C++ lets you do that too, so it is in fact reasonable to write that, though that's not quite "repr C" (C doesn't let you), and repr(u32) already gets you the same behavior.

However RFC 2195 seems to define repr(C, u32) as the same as repr(u32) on dataful enums, so it would be nice to have consistency here.