New lints: Changes to enum variant discriminants

[obi1kenobi]

Background on discriminants: https://doc.rust-lang.org/reference/items/enumerations.html#discriminants

We're looking for four lints total:

• a public API enum's variant used to have a well-defined discriminant, but no longer does — two cases:
  • the enum has an explicit representation, like #[repr(u8)] or #[repr(i64)]
  • the enum does not have an explicit representation
• a public API enum's variant had its discriminant has changed from its previous value: @dmatos2012
  • the enum has an explicit representation, like #[repr(u8)] or #[repr(i64)]
  • the enum does not have an explicit representation: Add enum variant discriminant changed lint #912

We distinguish between the repr/no-repr cases so that we can offer better error messages. When an enum has an explicit repr, that imposes an ABI (application binary interface) constraint in addition to the API constraint. Without a repr, the numeric value of the discriminant is fixed but its binary representation is not and could be anything.

For examples of querying the repr properly, please look at the enum_repr_int_changed lint. Make sure to include test cases where the repr is #[repr(C, i64)] or #[repr(u8, C)] since both variants are allowed too. The lints must appropriately detect the integer repr in both these cases and more straightforward ones like #[repr(i8)].

[dmatos2012]

Ill take the the 2nd bullet point, a public API enum's variant had its discriminant has changed from its previous value lint, which will cover the two bullet points you mention :)

[obi1kenobi]

Cool, got you marked as owning that. Are you still working on #885 as well, or is that blocked on something?

[dmatos2012]

Cool, got you marked as owning that. Are you still working on #885 as well, or is that blocked on something?

answered

[obi1kenobi]

Ah @dmatos2012 we actually want four lints for this issue, not two. The second bullet point describes two lints, since we want to lint for "you're breaking ABI" (such as for FFI use cases) separately from "you are breaking API." That will let us make stronger statements than "may break FFI", since hedging is generally bad when reporting errors.