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

Non-exhaustive pattern diagnostic include #[stable(...)] annotation #90820

Closed
jsha opened this issue Nov 12, 2021 · 5 comments
Closed

Non-exhaustive pattern diagnostic include #[stable(...)] annotation #90820

jsha opened this issue Nov 12, 2021 · 5 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jsha
Copy link
Contributor

jsha commented Nov 12, 2021

Given the following code

fn foo() {
    let result = Some(1i32);
    match result {
        Some(r) if r != 0 => {}
        None => {}
    }
}

The current output is:

    Checking mystery v0.1.0 (/home/jsha/learnrust/mystery)
error[E0004]: non-exhaustive patterns: `Some(_)` not covered
   --> src/lib.rs:3:11
    |
3   |     match result {
    |           ^^^^^^ pattern `Some(_)` not covered
    |
   ::: /home/jsha/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:518:5
    |
518 |     Some(#[stable(feature = "rust1", since = "1.0.0")] T),
    |     ---- not covered
    |
    = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
    = note: the matched value is of type `Option<i32>`

For more information about this error, try `rustc --explain E0004`.

Ideally the output should look like:

    Checking mystery v0.1.0 (/home/jsha/learnrust/mystery)
error[E0004]: non-exhaustive patterns: `Some(_)` not covered
   --> src/lib.rs:3:11
    |
3   |     match result {
    |           ^^^^^^ pattern `Some(_)` not covered
    |
    = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
    = note: the matched value is of type `Option<i32>`

For more information about this error, try `rustc --explain E0004`.
error: could not compile `mystery` due to previous error

The #[stable(...)] tag is a directive for documentation, but should not be included in this diagnostic.

This bug exists for me locally in stable and nightly, installed via rustup. Oddly, it does not reproduce on the playground.

@jsha jsha added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 12, 2021
@meithecatte
Copy link
Contributor

Perhaps you have the rust-src component installed while the playground doesn't?

@estebank
Copy link
Contributor

It's pointing at the enum variant, not at the stable annotation. That annotation is for the inner field T on Some.

@jsha
Copy link
Contributor Author

jsha commented Nov 24, 2021

Ah, @NieDzejkob, you're right I have rust-src installed:

$ rustup component list
...
rust-src (installed)

Is that not installed by default for most people?

It's pointing at the enum variant, not at the stable annotation. That annotation is for the inner field T on Some.

Yep, that makes sense to me. So if I'm understanding right: when rust-src is installed, some extra diagnostics will show up that point to specific lines in Rust stdlib source files, and those lines will naturally contain stability annotations. I had previously been under the impression that stability annotations would be hidden in output like this, but I think that was incorrect.

@estebank
Copy link
Contributor

estebank commented Nov 24, 2021

Your understanding is correct. The attributes aren't hidden, just not included in the span when they are outer attributes, but in this case it is the outer attribute of a field inside of the thing being displayed. This would be solved by this old PR of mine, but it needs some fixes to the underlying machinery on its previous PR.

@jsha
Copy link
Contributor Author

jsha commented Nov 24, 2021

Thanks for the explanations! I'll consider this working as intended, then.

@jsha jsha closed this as completed Nov 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints 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

3 participants