Vscode rust-analyzer: Usability of diagnostic output

The code below is known broken - I'd like to review the diagnostic output from Rust Analyzer (nightly) in Visual Studio Code (current release) on that:

trait SomeInteger         { fn bleep(&self);   }
impl  SomeInteger for i8  { fn bleep(&self) {} }
impl  SomeInteger for i32 { fn bleep(&self) {} }

fn bleep_it(a: Box<dyn SomeInteger>) {
    a.bleep();
}

fn main() {
    let number_of_yaks = 3;

    bleep_it(Box::new(number_of_yaks));
    print!("we have run out of {yaks} to shave");
}

The above source code yields diagnostic output in Rust Analyzer where I have highlighted the one root cause of all these diagnostics somewhere buried deep inthe middle of a pile of things:

...
rustc emits
...

error[E0425]: cannot find value `yaks` in this scope
  --> src/tracing_error.rs:13:32
   |
13 |     print!("we have run out of {yaks} to shave");
   |                                ^^^^^^ not found in this scope

error[E0283]: type annotations needed for `{integer}`
  --> src/tracing_error.rs:12:14
   |
10 |     let number_of_yaks = 3;
   |         -------------- consider giving `number_of_yaks` a type
11 | 
12 |     bleep_it(Box::new(number_of_yaks));
   |              ^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for type `{integer}`
   |
note: multiple `impl`s satisfying `{integer}: SomeInteger` found
  --> src/tracing_error.rs:2:1
   |
2  | impl  SomeInteger for i8  { fn bleep(&self) {} }
   | ^^^^^^^^^^^^^^^^^^^^^^^^
3  | impl  SomeInteger for i32 { fn bleep(&self) {} }
   | ^^^^^^^^^^^^^^^^^^^^^^^^^
   = note: required for the cast to the object type `dyn SomeInteger`

...
which has different ordering - and which in this case is much more applicable.

Is there a way in Rust Analyzer to, perhaps, get the diagnostic output into a better shape?

To anyone reading this, the author has posted about this code several times:

Thanks, again, @alice, for your response here.

This is not a duplicate posting - although I admittedly used the same source code, but here I am asking about an IDE challenge, not about type inference in rustc.

It seems as if the Visual Studio Code extension "Cargo" (Cargo - Visual Studio Marketplace) in v0.2.3 might interfere with Rust Analyzer; when combined (or rather: with "Cargo" enabled), the diagnostic output is as shown.

With "Cargo" disabled (or uninstalled) the output is cleaned up to

image

which (still) has different ordering compared to the raw rustc output, where the order of the rustc output might be better (because it is domain specific, not necessarily line order based?).

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.