about summary refs log tree commit diff
path: root/compiler/rustc_resolve/src
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2020-09-01 13:36:52 +0000
committerbors <bors@rust-lang.org>2020-09-01 13:36:52 +0000
commit397db054cb1f3d98e3d2809d25c60f1979cd5a97 (patch)
treeacc9eb26a2489bbe4adf478d0f50020f7040ba64 /compiler/rustc_resolve/src
parente88e908e66cd1e6e30d789b37bcd774951d01856 (diff)
parent1d157ce797dddcee16a577796199b1144b4f7f34 (diff)
downloadrust-397db054cb1f3d98e3d2809d25c60f1979cd5a97.tar.gz
rust-397db054cb1f3d98e3d2809d25c60f1979cd5a97.zip
Auto merge of #75529 - bugadani:bounds-check, r=nagisa
Eliminate some other bound checks when index comes from an enum

#36962 introduced an assumption for the upper limit of the enum's value. This PR adds an assumption to the lower value as well.

I've modified the original codegen test to show that derived (in that case, adding 1) values also don't generate bounds checks.

However, this test is actually carefully crafted to not hit a bug: if the enum's variants are modified to 1 and 2 instead of 2 and 3, the test fails by adding a bounds check. I suppose this is an LLVM issue and #75525, while not exactly in this context should be tracking it.

I'm not at all confident if this patch can be accepted, or even if it _should_ be accepted in this state. But I'm curious about what others think :)

~Improves~ Should improve #13926 but does not close it because it's not exactly predictable, where bounds checks may pop up against the assumptions.
Diffstat (limited to 'compiler/rustc_resolve/src')
0 files changed, 0 insertions, 0 deletions