diff options
| author | bors <bors@rust-lang.org> | 2019-11-15 23:28:50 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2019-11-15 23:28:50 +0000 |
| commit | 82161cda33406ae8dda08b3e4afe97a44b193792 (patch) | |
| tree | 2ae422e100de8b311906a73ddb011a143fa74ee6 /src/liballoc/alloc | |
| parent | 1bd30ce2aac40c7698aa4a1b9520aa649ff2d1c5 (diff) | |
| parent | 694a511df5e7473a696b50d30c3428bd0d54f140 (diff) | |
| download | rust-82161cda33406ae8dda08b3e4afe97a44b193792.tar.gz rust-82161cda33406ae8dda08b3e4afe97a44b193792.zip | |
Auto merge of #66326 - Nadrieril:refactor-intrange, r=varkor
Refactor integer range handling in the usefulness algorithm Integer range handling had accumulated a lot of debt. This cleans up a lot of it. In particular this: - removes unnecessary conversions between `Const` and `u128`, and between `Constructor` and `IntRange` - clearly distinguishes between on the one hand ranges of integers that may or may not be matched exhaustively, and on the other hand ranges of non-integers that are never matched exhaustively and are compared using Const-based shenanigans - cleans up some overly complicated code paths - generally tries to be more idiomatic. As a nice side-effect, I measured a 10% perf increase on `unicode_normalization`. There's one thing that I feel remains to clean up: the [overlapping range check](https://github.com/rust-lang/rust/pull/64007), which is currently quite ad-hoc. But that is intricate enough that I'm leaving it out of this PR. There's also one little thing I'm not sure I understand: can `try_eval_bits` fail for an integer constant value in that code ? What would that mean, and how do I construct a test case for this possibility ?
Diffstat (limited to 'src/liballoc/alloc')
0 files changed, 0 insertions, 0 deletions
