The following code snippet is known broken, but triggers an additional error diagnostic where I do not understand how this can be:
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");
}
My error is on the last line; {yaks}
for non-existing yaks
will not work - that is something the compiler will rightfully complain about.
But in the presence of that error, the compiler also emits an additional mystifying error message "type annotations needed for type integer":
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
It would seem as if the error on the {yaks} results in a full abort on type inference, and with type inference, no types get resolved, hence the subsequent error flagging the need for type annotations.
Questions:
a) is my speculation on that rustc implementation detail correct - i.e. no type inference stage in the above scenario?
b) I suspect the ordering of the errors is due to accumulation of errors over multiple stages, hence the format string problem is detected first, (then no type inference taking place), then complaints about being unable to get resolved types?
I realize that these are probably rustc implementation details, but then we are working with an implementation of a real compiler.
The reason for this posting: I am trying to learn how to efficiently read rust compiler error messages, so any explanation for the above or general approaches how to "work out the true problems" would be much appreciated.