Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

slice pattern bug #24875

Closed
mind-zz opened this issue Apr 27, 2015 · 3 comments
Closed

slice pattern bug #24875

mind-zz opened this issue Apr 27, 2015 · 3 comments

Comments

@mind-zz
Copy link

mind-zz commented Apr 27, 2015

The following program prints 102. Commenting out the match arm for either 100 or 102 causes the correct value (101) to be printed. I believe the first and third cases are being merged as they have the same form (but different guards), ruining the priority.

#![feature(slice_patterns)]

fn main() {
    let v = vec![1, 2];
    println!("{}", test(&v));
}

fn test(a: &[u64]) -> u64 {
    match a {
        [a, b ..]  if a == 3  => 100,
        [a, b]     if a == 1  => 101,
        [a, b ..]             => 102,
        _                     => 103
    }
}
// rustc 1.1.0-dev (69e47c77b 2015-04-23) (built 2015-04-23)
@mind-zz
Copy link
Author

mind-zz commented Jul 15, 2015

I'm actually seeing similar behavior even without guards (rest pattern overriding an earlier fixed-arity pattern).

eefriedman added a commit to eefriedman/rust that referenced this issue Jul 15, 2015
The old code was not well structured, difficult to understand,
and buggy.

The new implementation is completely naive, so there may be a slight
runtime performance loss. That said, adding optimizations on top of
a clear and correct implementation seems easier than trying to
fix the old mess.

Fixes issue rust-lang#19064.
Fixes issue rust-lang#26989.
Fixes issue rust-lang#26251.
Fixes issue rust-lang#18060.
Fixes issue rust-lang#24875.
Fixes issue rust-lang#23311.
Fixes issue rust-lang#20046.
@jfirebaugh
Copy link
Contributor

@arielb1
Copy link
Contributor

arielb1 commented Sep 12, 2016

Sure. Bug never existed in MIR.

@arielb1 arielb1 closed this as completed Sep 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants