Change:
lty: Ty<'tcx>, witness_preference: WitnessPreference, hir_id: HirId, <ins> is_under_guard: bool, </ins> ) -> Usefulness<'tcx, 'p> { debug!("is_useful_specialized({:#?}, {:#?}, {:?})", v, ctor, lty);

Discussion:
Not much to comment about. The supposedly “unreachable” pattern is obviously reached. () Output: Errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this was injected in 1.41.0, ostensibly in the exhaustiveness checking refactorings. To find out, let's cc ping cleanup cc
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
The relevant code is in : From the point of exhaustiveness checking this algorithm is correct, but not from a linting POV in the presence of guards. Previously, before the or-patterns reform, we merely interpreted each as a separate arm, so this was correctly handled from a linting perspective in the arm. Now however, the linting will happen in the arm, as according to , unaware of whether the arm , the pattern itself has an unreachable alternative. To fix this, presumably we have to propagate into , while being careful not to declare anything exhaustive which isn't for the soundness sensitive bits.
In case this is still relevant.. I went trying out and it gave me: regressed nightly: nightly-2019-12-04 regressed commit:
I'm going to assume we're ok with not detecting as redundant, otherwise we violate one of the assumptions of match checking, namely that variables and wildcards behave identically, and that's a whole other can of worms. Agreed. Specifically, what we want to avoid is adding to the matrix any pattern that is under a match guard. The code in does that correctly, but the or-pattern-handling code in doesn't. Once again I can't fix that myself right now, but I suspect it should be enough to disable this line: when we are under a match guard. So passing a bool to (recursively) should do the trick. (or anyone really) would you mind trying that ?

:angel: Two more test cases to be sure we're doing it right:
With such clear instructions, this looks like a good issue for beginners! I'll add the labels.
Hi, I want to take this I understand the solution explained by but have one question regarding because it also calls . From what I gather it generates a wildcard pattern and check it isn't useful, so for this task I can treat it as having no guard right?
assign
Absolutely !
Thanks for tackling this. :) I think it would also be neat to add some comments on around what it means to pass in "yes it has a guard", specifically that it shouldn't be relied on for soundness (i.e. in ). Perhaps also consider an or some such for robustness (consider also turning into for stronger typing). Best of luck!
-- that seems like quite a reasonable tradeoff for what is a rare occurrence. :)
I don't think this is any more readable, or safe, than a . The variable name makes it very clear in the method, and we can comment the call site if that seems ambiguous.