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

typeck: diverging binding in pattern does not generate unreachable_code #68429

Open
Centril opened this issue Jan 21, 2020 · 1 comment
Open
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-bug Category: This is a bug. C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Jan 21, 2020

The following should probably result in the lint being emitted:

#![feature(never_type)]

pub fn foo(maybe_never: Option<!>) {
    match maybe_never {
        Some(_never) => {
            println!("foo");
        }
        None => {}
    }
}

as _never is matched on, and it has a diverging type.

Compare this with:

#![feature(never_type)]

pub fn foo(maybe_never: Option<!>) {
    match maybe_never {
        Some(never) => {
            let _ = never;
            println!("foo");
        }
        None => {}
    }
}

Currently, the pattern type checking code does not care about diverges.

We should probably avoid fixing this in typeck and have this be fixed automatically (?) by moving diverges logic to MIR or some such.

cc @eddyb #68422 (comment).

@Centril Centril added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Jan 21, 2020
@Nadrieril
Copy link
Member

When using #![feature(exhaustive_patterns)], in both cases the whole branch will be detected to be unreachable. If exhaustive_patterns gets stabilized, would that supercede this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-bug Category: This is a bug. C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants