Tracking issue for future-incompatibility lint conflicting_repr_hints

[Centril]

This is the summary issue for a bug fix related to repr(...) hints. The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around future-compatibility warnings, see our breaking change policy guidelines.

What is the warning for?

The compiler incorrectly accepts #[repr(...)] hints on data types where the hints are incompatible and have conflicts. Examples of this includes:

// from `src/test/ui/conflicting-repr-hints.rs

#[repr(u32, u64)] //~ ERROR conflicting representation hints
enum D {
    D,
}

We are presently issuing a deny-by-default lint when conflicting representation hints are used together but we expect to transition the lint to hard errors in the future.

How can you fix your code?

Generally speaking, the conflict should be fixed by more clearly expressing your intent so that the conflict is resolved.

[Manishearth]

As discussed a bit in #68428 perhaps we should remove the warning and add semantics for #[repr(C, Int)] (namely, "fold into repr(C)").

C++ supports enum class Foo: uint16_t, and we heavily recommend you only pass repr(C) types across FFI boundaries, so it makes sense that the correct thing to write for this is #[repr(C, u16)]. Furthermore, for dataful enums, #[repr(C, u16)] actually does work, and it's weird for this not to be consistent.

[Centril]

Beta crater results in #68586 (comment):

error[E0566]: conflicting representation hints

Number of crates regressed: 2

* [`enum-utils v0.1.2`](https://crater-reports.s3.amazonaws.com/beta-1.42-1/beta-2020-02-05/reg/enum-utils-0.1.2/log.txt)

* [`ovr-mobile-sys v0.4.0`](https://crater-reports.s3.amazonaws.com/beta-1.42-rustdoc-1/beta-2020-02-05/reg/ovr-mobile-sys-0.4.0/log.txt)

• enum-utils has 0 rev deps, (btw, cc @ecstatic-morse)
• ovr-mobile-sys was the servo dependency and it seems to have been fixed already.

Based on these very limited results I don't think it's justified to retcon this into the specification, and making it an error again in the near future should be possible.

[ecstatic-morse]

enum-utils has a test that ensures #[repr(C, u16)] works. You shouldn't consider it when determining fallout.

[marmeladema]

Just encountered this error.
I wonder how does it relate to

• RFC 2195: Formally define repr(u32, i8, etc...) and repr(C) on enums with payloads rfcs#2195
• RFC 2363: Tracking issue for RFC 2363, "Allow arbitrary enums to have explicit discriminants" #60553

Will that make both those RFC obsolete?
Also, will it be turned into a hard error in edition 2021?