Error location incorrectly extracted inside macros.

[omerbenamram]

It seems that rust-analyzer can sometimes incorrectly resolve location of an error, to a non-existing location such as <::alloc::macros::vec macros>.

The compiler resolves those spans nicely:

error[E0308]: mismatched types
   --> intcode-computer\./src/lib.rs:438:36
    |
438 |         test_memory!("1,0,0,0,99", vec![], "2,0,0,0,99");
    |                                    ^^^^^^ expected &[i64], found struct `std::vec::Vec`
    |
    = note: expected type `&[i64]`
               found type `std::vec::Vec<_>`
    = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) 

I tried to minimize it very crudely, but it didn't seem to always occur, at least not in this example:

macro_rules! my_macro {
    ($t: expr) => {
        a($t);
    };
}

fn a(v: &[i64]) {
    unimplemented!()
}

fn main() {
    let x = 0_i64;
    my_macro!(vec![1])
}

which seems to resolve fine to main.rs:

This reproduces on my advent of code repo https://github.com/omerbenamram/AOC2019/.

I'm not sure which part of rust-analyzer is responsible for this behavior, but I could take a look in a general direction if it's not too complex.

[bjorn3]

This is not emitted by rust-analyzer itself, but by cargo watch which runs cargo check after every change. The location of the error is technically correct, as it refers to the expansion of the vec! macro. Rustc has special casing for macros outside the current crate, but I think the json output doesn't.

[omerbenamram]

@bjorn3 I see now, it does seem to be the information returning from cargo check.
running cargo check --message-format=json | rg alloc | jq | rg -C 20 alloc reveals it:

...
    "code": {
      "code": "E0308",
      "explanation": "\nThis error occurs when the compiler was unable to infer the concrete type of a\nvariable. It can occur for several cases, the most common of which is a\nmismatch in the expected type that the compiler inferred for a variable's\ninitializing expression, and the actual type explicitly assigned to the\nvariable.\n\nFor example:\n\n```compile_fail,E0308\nlet x: i32 = \"I am not a number!\";\n//     ~~~   ~~~~~~~~~~~~~~~~~~~~\n//      |             |\n//      |    initializing expression;\n//      |    compiler infers type `&str`\n//      |\n//    type `i32` assigned to variable `x`\n```\n"
    },
    "level": "error",
    "message": "mismatched types",
    "spans": [
      {
        "byte_end": 140,
        "byte_start": 102,
        "column_end": 63,
        "column_start": 25,
        "expansion": {
          "def_site_span": {
            "byte_end": 198,
            "byte_start": 0,
            "column_end": 55,
            "column_start": 1,
            "expansion": null,
            "file_name": "<::alloc::macros::vec macros>",
            "is_primary": false,
            "label": null,
            "line_end": 3,
            "line_start": 1,
            "suggested_replacement": null,
            "suggestion_applicability": null,
            "text": [
              {
                "highlight_end": 78,
                "highlight_start": 1,
                "text": "($ elem : expr ; $ n : expr) => ($ crate :: vec :: from_elem ($ elem, $ n)) ;"
              },
              {
                "highlight_end": 66,
                "highlight_start": 1,
                "text": "($ ($ x : expr), *) => (< [_] > :: into_vec (box [$ ($ x), *])) ;"
              },
              {
                "highlight_end": 55,
                "highlight_start": 1,

But it seems cargo is clever enough to work around it when it prints the errors, neat.

[bjorn3]

Cargo just looks at the rendered field, not the rest of the json blob.

[omerbenamram]

@bjorn3 what I meant was that it is rendered it correctly shows the file where the final error has occured.

If we look at an entire error - we could see that while .spans[0].file_name is indeed <::alloc::macros::vec macros>.
However - under expansion there is additional information provided an inner span, with the actual file labeled day9\\./src/lib.rs.

It would have been nice if we could send this to the editor, so it would actually point us to the correct location.

{
  "reason": "compiler-message",
  "package_id": "day7 0.1.0 (path+file:///C:/Workspace/AOC2019/day7)",
  "target": {
    "kind": [
      "lib"
    ],
    "crate_types": [
      "lib"
    ],
    "name": "day7",
    "src_path": "C:\\Workspace\\AOC2019\\day7\\./src/lib.rs",
    "edition": "2018",
    "doctest": true
  },
  "message": {
    "rendered": "error[E0308]: mismatched types\n  --> day7\\./src/lib.rs:58:28\n   |\n58 |         amp.write_to_input(vec![inputs[i]])?;\n   |                            ^^^^^^^^^^^^^^^ expected &[i64], found struct `std::vec::Vec`\n   |\n   = note: expected type `&[i64]`\n              found type `std::vec::Vec<i64>`\n   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)\n\n",
    "children": [
      {
        "children": [],
        "code": null,
        "level": "note",
        "message": "expected type `&[i64]`\n   found type `std::vec::Vec<i64>`",
        "rendered": null,
        "spans": []
      }
    ],
    "code": {
      "code": "E0308",
      "explanation": "\nThis error occurs when the compiler was unable to infer the concrete type of a\nvariable. It can occur for several cases, the most common of which is a\nmismatch in the expected type that the compiler inferred for a variable's\ninitializing expression, and the actual type explicitly assigned to the\nvariable.\n\nFor example:\n\n```compile_fail,E0308\nlet x: i32 = \"I am not a number!\";\n//     ~~~   ~~~~~~~~~~~~~~~~~~~~\n//      |             |\n//      |    initializing expression;\n//      |    compiler infers type `&str`\n//      |\n//    type `i32` assigned to variable `x`\n```\n"
    },
    "level": "error",
    "message": "mismatched types",
    "spans": [
      {
        "byte_end": 140,
        "byte_start": 102,
        "column_end": 63,
        "column_start": 25,
        "expansion": {
          "def_site_span": {
            "byte_end": 198,
            "byte_start": 0,
            "column_end": 55,
            "column_start": 1,
            "expansion": null,
            "file_name": "<::alloc::macros::vec macros>",
            "is_primary": false,
            "label": null,
            "line_end": 3,
            "line_start": 1,
            "suggested_replacement": null,
            "suggestion_applicability": null,
            "text": [
              {
                "highlight_end": 78,
                "highlight_start": 1,
                "text": "($ elem : expr ; $ n : expr) => ($ crate :: vec :: from_elem ($ elem, $ n)) ;"
              },
              {
                "highlight_end": 66,
                "highlight_start": 1,
                "text": "($ ($ x : expr), *) => (< [_] > :: into_vec (box [$ ($ x), *])) ;"
              },
              {
                "highlight_end": 55,
                "highlight_start": 1,
                "text": "($ ($ x : expr,) *) => ($ crate :: vec ! [$ ($ x), *])"
              }
            ]
          },
          "macro_decl_name": "vec!",
          "span": {
            "byte_end": 1883,
            "byte_start": 1868,
            "column_end": 43,
            "column_start": 28,
            "expansion": null,
            "file_name": "day7\\./src/lib.rs",
            "is_primary": false,
            "label": null,
            "line_end": 58,
            "line_start": 58,
            "suggested_replacement": null,
            "suggestion_applicability": null,
            "text": [
              {
                "highlight_end": 43,
                "highlight_start": 28,
                "text": "        amp.write_to_input(vec![inputs[i]])?;\r"
              }
            ]
          }
        },
        "file_name": "<::alloc::macros::vec macros>",
        "is_primary": true,
        "label": "expected &[i64], found struct `std::vec::Vec`",
        "line_end": 2,
        "line_start": 2,
        "suggested_replacement": null,
        "suggestion_applicability": null,
        "text": [
          {
            "highlight_end": 63,
            "highlight_start": 25,
            "text": "($ ($ x : expr), *) => (< [_] > :: into_vec (box [$ ($ x), *])) ;"
          }
        ]
      }
    ]
  }
}

[edwin0cheng]

@omerbenamram The actual cargo message to vs diagnostic parsing is in here :

https://github.com/rust-analyzer/rust-analyzer/blob/e292573f425eece6f1666e051d7fe64b79640d39/editors/code/src/utils/diagnostics/rust.ts#L185

I think maybe we could validate the file_name in spans and fall back to main error message if it is invalid ?

[bjorn3]

Or look at spans[].expansion.span when the filename contains macros>. (recursively descending when that span is from a macro too.

[omerbenamram]

@bjorn3 I'm not super familiar with the JSON format cargo check uses - but this sounds about right (at least in this case) :)

[edwin0cheng]

@omerbenamram It can be close now, right?

[omerbenamram]

@edwin0cheng It works perfectly now! Thanks!!