Document ABI changes from #[repr(u*)] enum

Author: geofft

src/other-reprs.md

@@ -37,6 +37,13 @@ enum representation in C is implementation defined, so this is really a "best
 guess". In particular, this may be incorrect when the C code of interest is
 compiled with certain flags.
 
+* "C-like" enums with `repr(C)` or `repr(u*)` still may not be set to an
+integer value without a corresponding variant, even though this is
+permitted behavior in C or C++. It is undefined behavior to (unsafely)
+construct an instance of an enum that does not match one of its
+variants. (This allows exhaustive matches to continue to be written and
+compiled as normal.)
+
 
 
 # repr(u8), repr(u16), repr(u32), repr(u64)
@@ -47,8 +54,17 @@ ask Rust to allow this by setting the overflowing element to explicitly be 0.
 However Rust will not allow you to create an enum where two variants have the
 same discriminant.
 
-On non-C-like enums, this will inhibit certain optimizations like the null-
-pointer optimization.
+If a C-like enum is missing a `repr(u*)` or `repr(C)`, it is treated
+like a one-member struct for ABI compatibility purposes. This means
+that, for instance, some ABIs will unconditionally pass it on the stack
+instead of in a register. Adding a `repr` causes it to be treated
+exactly like the specified integer size for ABI purposes.
+
+However, a non-C-like enum will always be treated like a struct (even if
+the only data is `()` or `PhantomData`). Adding `repr` simply forces the
+discriminant to be represented in memory by the specified integer size.
+This does have the effect of inhibiting certain optimizations like the
+null-pointer optimization.
 
 These reprs have no effect on a struct.