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

stray "not covered" diagnostic in JSON output #64769

Closed
ehuss opened this issue Sep 25, 2019 · 7 comments
Closed

stray "not covered" diagnostic in JSON output #64769

ehuss opened this issue Sep 25, 2019 · 7 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ehuss
Copy link
Contributor

ehuss commented Sep 25, 2019

Since #64271, the E0005 error has begun emitting a strange "not covered" span in the JSON output. This does not appear in the normal "human" rendered output.

Sample code:

#![allow(unused)]

fn main() {
    let x = Some(1);
    let Some(y) = x;
}

With --error-format=json, this includes the following span which looks broken to me:

   {
    "byte_end": 0,
    "byte_start": 0,
    "column_end": 1,
    "column_start": 1,
    "expansion": null,
    "file_name": "src/main.rs",
    "is_primary": false,
    "label": "not covered",
    "line_end": 1,
    "line_start": 1,
    "suggested_replacement": null,
    "suggestion_applicability": null,
    "text": [
      {
        "highlight_end": 1,
        "highlight_start": 1,
        "text": "#![allow(unused)]"
      }
    ]
  }

For tools that consume JSON output, this results in a strange message being displayed.

cc @Centril

@jonas-schievink jonas-schievink added A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 25, 2019
@Centril
Copy link
Contributor

Centril commented Sep 25, 2019

Can you check if this reproduces for match before the PR?

Seems to be a cross crate issue?

#![allow(unused)]

enum O<T> { Some(T), None, }

use O::*;

fn main() {
    let x = Some(1);
    let Some(y) = x;
}

shows not covered.

Relevant code:

err.span_label(sp, "not covered");

cc @estebank

@estebank
Copy link
Contributor

It's likely pointing at a DUMMY_SP, consistent with

    "byte_end": 0,
    "byte_start": 0,
    "column_end": 1,
    "column_start": 1,

This is probably coming from desugaring. We can add a test around the span_label for this case, but we probably just do the same thing we do in the visual output and ignore DUMMY_SPs.

@ehuss
Copy link
Contributor Author

ehuss commented Sep 25, 2019

Oh, I see. Yea, it works correctly for your example. I guess it is trying to point to the definition of Option, but it is a dummy span.

@estebank
Copy link
Contributor

How critical is this? Namely, how quickly do we need a fix? Fixing for this one test is a small pr, fixing the general case will be more arduous, I think.

@ehuss
Copy link
Contributor Author

ehuss commented Sep 25, 2019

For me, not critical at all. It would be nice to eventually get it fixed, but there is absolutely no rush.

@estebank estebank added the P-low Low priority label Nov 8, 2019
@steveklabnik
Copy link
Member

Triage: I believe this is fixed? I'm seeing "label":"expected one of!or::", now.

@ehuss
Copy link
Contributor Author

ehuss commented Jan 5, 2021

Thanks for checking @steveklabnik, I think the dummy span issue was resolved by #70199.

@ehuss ehuss closed this as completed Jan 5, 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 C-bug Category: This is a bug. P-low Low priority 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

5 participants