397db054cb
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. |
||
---|---|---|
.. | ||
rustc | ||
rustc_apfloat | ||
rustc_arena | ||
rustc_ast | ||
rustc_ast_lowering | ||
rustc_ast_passes | ||
rustc_ast_pretty | ||
rustc_attr | ||
rustc_builtin_macros | ||
rustc_codegen_llvm | ||
rustc_codegen_ssa | ||
rustc_data_structures | ||
rustc_driver | ||
rustc_error_codes | ||
rustc_errors | ||
rustc_expand | ||
rustc_feature | ||
rustc_fs_util | ||
rustc_graphviz | ||
rustc_hir | ||
rustc_hir_pretty | ||
rustc_incremental | ||
rustc_index | ||
rustc_infer | ||
rustc_interface | ||
rustc_lexer | ||
rustc_lint | ||
rustc_macros | ||
rustc_metadata | ||
rustc_middle | ||
rustc_mir | ||
rustc_mir_build | ||
rustc_parse | ||
rustc_parse_format | ||
rustc_passes | ||
rustc_plugin_impl | ||
rustc_privacy | ||
rustc_query_system | ||
rustc_resolve | ||
rustc_save_analysis | ||
rustc_serialize | ||
rustc_session | ||
rustc_span | ||
rustc_symbol_mangling | ||
rustc_target | ||
rustc_trait_selection | ||
rustc_traits | ||
rustc_ty | ||
rustc_typeck |