Ensure we don't subtract with underflow getting enum names

[mmastrac]

Fixes #5245:

The code generated for enum names underflows when attempting to get an enum name for one of the negative values (panicked at 'attempt to subtract with overflow'):

pub fn enum_name_xyz(e: XYZ) -> &'static str {
  let index: usize = e as usize - XYZ::NEGATIVE_VALUE as usize;
  ENUM_NAMES_XYZ[index]
}

Instead, the code should cast the left and right to the underlying representation (ie: i8), then cast that result to usize:

pub fn enum_name_xyz(e: XYZ) -> &'static str {
  let index = e as i8 - XYZ::NEGATIVE_VALUE as i8;
  ENUM_NAMES_XYZ[index as usize]
}

[rw]

is the idea that this helps with defensive programming? Because IIUC we would not expect to see negative values in the wild.

[mmastrac]

This turned out to be an issue in practice in our use. As it stands right now enums allow negative values. In our case we had a somewhat complicated issue where they needed to interop w/another system that required tight-packing of these enum values. The only way for us to fit our enum in an 8-byte value was to use negative numbers, which surfaced this issue w/names causing a panic.

Note that changing an enum to ubyte to avoid negative numbers has other issues (specifically w/Java) and could use a pass over the rest of the code-generators and libraries as well.

[mmastrac]

@rw Any further thoughts on this? I think officially enums should support negative values (or we should explicitly disallow them and error out at compile time, and fix any ubyte/ushort/etc issues).

[rw]

@aardappel WDYT about negative enums?

[aardappel]

@rw yes, negative enums are a valid use of enums and their existence should be taken into account. For using them as an index into an array, they either need to be offset by the smallest possible value (which may be negative), or if the set of values is too sparse it should not use indexing at all.

[mmastrac]

@rw @aardappel Is it ok if we merge this?

[aardappel]

I think so!