Missed optimization for `match`
Open
Nobody has claimed this yet.
C-optimization
T-compiler
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
I tried this code:
Code
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
pub enum GeneralCategory {
Lu,
Ll,
Lt,
Lm,
Lo,
Mn,
Mc,
Me,
Nd,
Nl,
No,
Pc,
Pd,
Ps,
Pe,
Pi,
Pf,
Po,
Sm,
Sc,
Sk,
So,
Zs,
Zl,
Zp,
Cc,
Cf,
Cs,
Co,
Cn,
}
#[unsafe(no_mangle)]
pub const fn is_ascii_alphabetic1(c: char) -> bool {
use GeneralCategory::*;
c >= '\u{0000}'
&& c <= '\u{007f}'
&& match match c {
'\u{0000}'..='\u{001F}' => Cc,
'\u{0020}' => Zs,
'\u{0021}'..='\u{0023}' => Po,
'\u{0024}' => Sc,
'\u{0025}'..='\u{0027}' => Po,
'\u{0028}' => Ps,
'\u{0029}' => Pe,
'\u{002A}' => Po,
'\u{002B}' => Sm,
'\u{002C}' => Po,
'\u{002D}' => Pd,
'\u{002E}'..='\u{002F}' => Po,
'\u{0030}'..='\u{0039}' => Nd,
'\u{003A}'..='\u{003B}' => Po,
'\u{003C}'..='\u{003E}' => Sm,
'\u{003F}'..='\u{0040}' => Po,
'\u{0041}'..='\u{005A}' => Lu,
'\u{005B}' => Ps,
'\u{005C}' => Po,
'\u{005D}' => Pe,
'\u{005E}' => Sk,
'\u{005F}' => Pc,
'\u{0060}' => Sk,
'\u{0061}'..='\u{007A}' => Ll,
'\u{007B}' => Ps,
'\u{007C}' => Sm,
'\u{007D}' => Pe,
'\u{007E}' => Sm,
'\u{007F}' => Cc,
_ => return false,
} {
Lu | Ll | Lt | Lm | Lo => true,
_ => false,
}
}
#[unsafe(no_mangle)]
pub const fn is_ascii_alphabetic2(c: char) -> bool {
use GeneralCategory::*;
c >= '\u{0000}'
&& c <= '\u{007f}'
&& match match c {
'\u{0041}'..='\u{005A}' => Lu,
'\u{0061}'..='\u{007A}' => Ll,
_ => return false,
} {
Lu | Ll | Lt | Lm | Lo => true,
_ => false,
}
}
I expected to see this happen: The code for is_ascii_alphabetic1 to be identical to the code of is_ascii_alphabetic2
Instead, this happened: The function is_ascii_alphabetic1 has a lot of code compared to the function is_ascii_alphabetic2.
Meta
rustc --version --verbose:
rustc 1.91.0-nightly (7d82b83ed 2025-08-06)
binary: rustc
commit-hash: 7d82b83ed57d188ab3f2441a765a6419685a88a3
commit-date: 2025-08-06
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No repository file, test, or entry point is named. Start by compiling the supplied Rust reproducer with the reported nightly and inspecting the generated code for both functions; done means the optimized output for is_ascii_alphabetic1 matches is_ascii_alphabetic2 without changing their behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100