Properly handle ranges of signed enums using both extremums (fixes #49973)

[nox]

Fixes #49973.

[rust-highfive]

r? @michaelwoerister

(rust_highfive has picked a reviewer for you, use r? to override)

[dtolnay]

Please add an assertion that size_of::<Option<E>>() == size_of::<E>(). I have not read the code but the use of valid_range: min..=max makes me slightly concerned that this may not be the case.

Or if that is too complicated to handle in this PR, please file an issue to follow up.

[nox]

Please add an assertion that size_of::<Option<E>>() == size_of::<E>(). I have not read the code but the use of valid_range: min..=max makes me slightly concerned that this may not be the case.

It is indeed not the case, which is why I didn't put a test for that. It's a known issue, though, there is a todo and whatnot in the code that some enums' valid ranges are larger than necessary. I'll file an actual issue on GH linking to it.

[dtolnay]

Sounds good, thanks.

[michaelwoerister]

r? @eddyb

[eddyb]

@bors r+

Do we want to backport this?

[bors]

📌 Commit a7c4b5c has been approved by eddyb

[bors]

⌛ Testing commit a7c4b5c with merge 65d201f...

[eddyb]

cc @rust-lang/compiler Regarding backporting (#49981 (comment))

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing 65d201f to master...