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

Incorrect "unreachable pattern" warning in Rust 1.50. #82012

Closed
AlephAlpha opened this issue Feb 12, 2021 · 4 comments
Closed

Incorrect "unreachable pattern" warning in Rust 1.50. #82012

AlephAlpha opened this issue Feb 12, 2021 · 4 comments
Labels
A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns C-bug Category: This is a bug. regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-release Relevant to the release subteam, which will review and decide on the PR/issue.
Milestone

Comments

@AlephAlpha
Copy link

This seems to be a new issue in Rust 1.50. The latest nightly does not have this issue.

macro_rules! some {
    ($item:pat) => {
        Some($item)
    };
}

fn main() {
    let a = Some('A');
    match a {
        some!('a') | some!('A') => println!("A!"),
        _ => println!("Not a!"),
    }
}

playground

It prints "A!" without any error, but gives the following warning.

warning: unreachable pattern
  --> src/main.rs:3:9
   |
3  |         Some($item)
   |         ^^^^^^^^^^^
...
10 |         some!('a') | some!('A') => println!("A!"),
   |                      ---------- in this macro invocation
   |
   = note: `#[warn(unreachable_patterns)]` on by default
   = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

warning: 1 warning emitted

some!('A') is obviously reachable, otherwise it won't print "A!".

@AlephAlpha AlephAlpha added the C-bug Category: This is a bug. label Feb 12, 2021
@jonas-schievink jonas-schievink added A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 12, 2021
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Feb 12, 2021
@jyn514 jyn514 added T-release Relevant to the release subteam, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 12, 2021
@jyn514
Copy link
Member

jyn514 commented Feb 12, 2021

This is #80501. It was fixed in #80632 but not backported to stable.

@jyn514
Copy link
Member

jyn514 commented Feb 12, 2021

cc @rust-lang/release, I don't know the policy for this sort of thing.

@Mark-Simulacrum Mark-Simulacrum added this to the 1.50.0 milestone Feb 12, 2021
@Mark-Simulacrum
Copy link
Member

Gah. The relevant PR was not tagged beta-nominated so was overlooked; as it closed #80501 the release team did not see that the regression was unfixed.

I am not sure this is worth a stable point release over, but I've now nominated the PR for beta backport (to 1.51, as it landed in 1.52) and stable backport (to 1.50).

@apiraino apiraino removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Feb 12, 2021
@workingjubilee
Copy link
Member

Resolved by the sands of time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns C-bug Category: This is a bug. regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-release Relevant to the release subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants