Change:
vec_len(/* length */ uint, VecLenOpt, /*range of matches*/(uint, uint)) } <ins> fn lit_to_expr(tcx: &ty::ctxt, a: &Lit) -> @ast::Expr { match *a { ExprLit(existing_a_expr) => existing_a_expr, ConstLit(a_const) => const_eval::lookup_const_by_id(tcx, a_const).unwrap(), UnitLikeStructLit(_) => fail!("lit_to_expr: unexpected struct lit"), } } </ins> fn opt_eq(tcx: &ty::ctxt, a: &Opt, b: &Opt) -> bool { match (a, b) { <ins> (&lit(UnitLikeStructLit(a)), &lit(UnitLikeStructLit(b))) => a == b, </ins> (&lit(a), &lit(b)) => { <del> match (a, b) { (UnitLikeStructLit(a), UnitLikeStructLit(b)) => a == b, _ => { let a_expr; match a { ExprLit(existing_a_expr) => a_expr = existing_a_expr, ConstLit(a_const) => { let e = const_eval::lookup_const_by_id(tcx, a_const); a_expr = e.unwrap(); } UnitLikeStructLit(_) => { fail!("UnitLikeStructLit should have been handled  above") } } let b_expr; match b { ExprLit(existing_b_expr) => b_expr = existing_b_expr, ConstLit(b_const) => { let e = const_eval::lookup_const_by_id(tcx, b_const); b_expr = e.unwrap(); } UnitLikeStructLit(_) => { fail!("UnitLikeStructLit should have been handled  above") } } match const_eval::compare_lit_exprs(tcx, a_expr, b_expr) { Some(val1) => val1 == 0, None => fail!("compare_list_exprs: type mismatch"), } } </del> <ins> let a_expr = lit_to_expr(tcx, &a); let b_expr = lit_to_expr(tcx, &b); match const_eval::compare_lit_exprs(tcx, a_expr, b_expr) { Some(val1) => val1 == 0, None => fail!("compare_list_exprs: type mismatch"), </ins> } } (&range(a1, a2), &range(b1, b2)) => {

Discussion:
The following code prints instead of : Removing the first arm () makes it print as expected.
Based on reading PR and the code, I think the bug is a bug in , which doesn't properly consider guards and the possible overlap between literals and ranges. However, I don't think the fix in PR is quite right -- is not meant to be a general "might match" check. What seems to currently do is to iterate over the list of patterns, given that the given option matched. So, in the example test case, the state would be that the remaining patterns are: (1) with guard (1, 2) and the opt here is . What incorrectly does is to consider 1 and 3 a match but not 2. I'm not....100% sure what the intended answer is here actually, and the introduction of a guard makes things more complicated. In particular I don't quite understand where the precedence of earlier matches comes into play. Imagine that there were no guard: in that case, I could imagine the correct answer being just 1, because that match has the highest precedence. But the code doesn't appear to be setup that way, it seems to test each option independently with no regard for order. Therefore I gather that it would yield (in the case with no guard) 1 and 3. And then I think in the next recursion call to , we would not consider option 3 because it is a "default" match. (Ah, I see. What was confusing me is how a match like this would work . It seems like we would infinitely recurse because would always yield both options. But the answer is that we rule these cases out by an earlier check, which reports that the second 1 is unreachable.) Note: may shed some light on the intended workings of the code. For some reason I haven't read it. I'm a glutton for punishment I guess. I really ought to, particularly since he writes so well. Based on all this, the right fix is... not immediately obvious to me. One option is to have consider guards and precedence, but as I said that doesn't seem to be what the code is setup to do. Another option is to handle guards early -- right now, if the next option in the list has a guard, we will execute it, but only if the pattern is fully matched.

I could imagine trying to test the remaining bits of pattern imperatively and test the guard, but that'd be a whole other code path (it might be one that we want, actually, if we are going to permit overloadable deref in that's a separate bug). Having unconditionally consider literals as matching against ranges feels a bit creepy. I think the code would fail to terminate for a test case like . Perhaps if the exhaustiveness check reported an error for this case, but it doesn't. Also, I think there is a related bug that the current patch would not solve, though if we patched up more thoroughly it might: My conclusion is thus that the best thing would be to change to consider guards and precedence, but I want to read marijn's article maybe and see if it offers a 3rd way.
I think I understand the logic of now. It translates the following: to something like: By the virtue of the fact that we are in already, assumes m1 is "stricter" than m2 because otherwise compiler should've bailed out with "unreachable pattern" error. Unfortunately, "m1 + guard" is not necessarily stricter than m2 since guard function may return false. Note, is translated correctly to: because we have exact equality of two here. So, we probably need to change the semantic of to do range overlap, single value + range overlap and range + single value overlap check after all. A possible optimization is that the extended check is only necessary if there's a guard.
I've revised . It now only touches and passes a more comprehensive test. It also Please review.