-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Incorrect "unreachable pattern" warning with opaque constant #78057
Comments
@rustbot modify labels: +A-exhaustiveness-checking |
How is the second branch reachable? |
A value like |
With this example, I get an error: I believe the warning is raised because the compiler then assumes you use FOO as a catch-all name instead? |
Oh, that's an interesting hypothesis. That would mean some part of the code sees this as a const pattern (hence the error) and some other part as a variable binding (hence the warning). I would find that quite surprising honestly. |
Nah, the bit that emits the error is in |
But if I derive |
Yeah, something happens when the const is considered opaque which triggers this behavior. I'm not sure what exactly, @oli-obk do you know? Maybe returning |
Oh wait that's exactly what happens :D rust/compiler/rustc_mir_build/src/thir/pattern/const_to_pat.rs Lines 337 to 348 in 6af9846
@oli-obk I believe to solve that particular issue we'd need to return something else than |
…, r=varkor Cleanup constant matching in exhaustiveness checking This supercedes rust-lang#77390. I made the `Opaque` constructor work. I have opened two issues rust-lang#78071 and rust-lang#78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately. I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior. EDIT: I accidentally fixed rust-lang#78071
…, r=varkor Cleanup constant matching in exhaustiveness checking This supercedes rust-lang#77390. I made the `Opaque` constructor work. I have opened two issues rust-lang#78071 and rust-lang#78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately. I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior. EDIT: I accidentally fixed rust-lang#78071
I gave it more thought, and the correct approach seems instead to not even start exhaustiveness checking if |
How about we introduce a |
There's already code in check_match to track errors and skip exhaustiveness, we could reuse that:
I'll add that to my queue of things to do |
yeah ok there's a complicated path from |
The code no longer emits this warning for this case. |
It does, I just tested with the same playground link. But it also emits an error so maybe the warning doesn't matter too much. I just think it's a bit confusing. Full output:
|
I tried this code (playground link):
This emits an "unreachable pattern" warning on the second branch of the match, even though it is clearly reachable. This gives the same warning for current nightly and beta, as well as stable 1.47.0 and 1.40.0.
This was uncovered while discussing #77390.
Meta
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: