overflowing_literals error is confusing because of type inference

While experimenting with the Rust By Example playground on the Inference section at https://doc.rust-lang.org/stable/rust-by-example/types/inference.html I came across what I believe is an error in the error produced by the compiler.

I do not expect this example to work but the error literal out of range for 'i8' is reported against line 4 let e2 = 230; which is a perfectly valid statement. The problem is lower down where two different types are pushed onto the same Vector but possibly due to the way the inference engine works this is being incorrectly reported against line 4. If I comment out the line vec.push(e2);, the example works fine, apart from a warning: unused variable: 'e2'.

Code

fn main() {
    // Because of the annotation, the compiler knows that `elem` has type i8.
    let elem = 6i8;
    let e2 = 230;

    // Create an empty vector (a growable array).
    let mut vec = Vec::new();
    // At this point the compiler doesn't know the exact type of `vec`, it
    // just knows that it's a vector of something (`Vec<_>`).

    // Insert `elem` in the vector.
    vec.push(e2);
    vec.push(elem);
    // Aha! Now the compiler knows that `vec` is a vector of `u8`s (`Vec<u8>`)
    // TODO ^ Try commenting out the `vec.push(elem)` line

    println!("{:?}", vec);
}

Error output

   Compiling playground v0.0.1 (/playground)
error: literal out of range for `i8`
 --> src/main.rs:4:14
  |
4 |     let e2 = 230;
  |              ^^^
  |
  = note: `#[deny(overflowing_literals)]` on by default
  = note: the literal `230` does not fit into the type `i8` whose range is `-128..=127`

error: aborting due to previous error

error: could not compile `playground`

To learn more, run the command again with --verbose.

Backtrace

Sorry I don't know exactly how to provide this.

<backtrace>

e2 also has type i8, because you push it onto the same Vec as elem, so the error message is correct – the literal is out of range for the target type i8

While that is true (and as I mentioned, I do not expect this to work) the problem is the error reported by the compiler doesn't help the user resolve the problem. In a small example like this it's easy to see where the problem lies but in a larger one the compiler error would send the user in the wrong direction.

okay, marking as a diagnostics enhancement

I'm guessing this would be hard to implement since we'd need to somehow track the spot(s) that caused us to infer a particular type.

Reposting my idea from Zulip:

Perhaps we could store something in the TyCtxt or Sess that maps every AST node to its "inference source". There would be a struct InferenceSource that would hold the spans that caused this node to be inferred to be a particular type:

pub struct InferenceSource {
    pub source_spans: Vec<Span>,
}

Over time we could add more fields if we wanted more detailed diagnostics.

I'm not sure how feasible that is, but seems potentially possible.

One thing we'd need to figure out is when and how much to show of the inference-source stack. In some situations, it may not be helpful, and in others it may be too much information.

In the first example, all the compiler knows is that e2 is an integer, so when it sees you push it into what it's inferred to be a Vec<i8>, it says "OK! I guess e2 must be an i8".

This had me confused for a bit as well, i.e. I'm first pushing e2 onto the Vector so I thought it would infer it to be Vec<i32> and then complain about adding the i8 but I guess the inference engine builds some kind of constraint model and uses the i8 even though it is pushed second because the e2 literal is not explicitly typed.

I experimented with let e2 = 2300; and let e2 = 2300i16; and in the first case it again reports literal out of range for 'i8' while in the second it reports mismatched types so I think I understand the inference model a little better!

One thing we'd need to figure out is when and how much to show of the inference-source stack. In some situations, it may not be helpful, and in others it may be too much information.

From an end-user perspective I couldn't follow much of what you said but if the diagnostic was to point to the line where the element was pushed (or otherwise used in a manner that causes a type mismatch) and not where it has its value set, that would be better.

I experimented with let e2 = 2300; and let e2 = 2300i16;

I think this suggests an inexpensive way forward for a diagnostic here: suggest that they add a suffix and recompile. For example, it could see the 230 and say something like "help: if you're unsure why it was inferred as i8, try changing it to 230_u8 and seeing where you get a type error". (Of course, if it's already suffixed, like 300_u8, then it shouldn't suggest that.)

That’s a good idea! :)

Rollup merge of rust-lang#79981 - camelid:overflowing_literals-infere…

Navigation Menu

Repository navigation

`overflowing_literals` error is confusing because of type inference #79744

Code

Meta

Error output

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

overflowing_literals error is confusing because of type inference #79744

Description

Code

Meta

Error output

Activity

jonas-schievink commented on Dec 5, 2020

shreepads commented on Dec 5, 2020

jonas-schievink commented on Dec 5, 2020

camelid commented on Dec 5, 2020

5 remaining items

camelid commented on Dec 6, 2020

camelid commented on Dec 6, 2020

camelid commented on Dec 6, 2020

shreepads commented on Dec 6, 2020

scottmcm commented on Dec 11, 2020

camelid commented on Dec 11, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`overflowing_literals` error is confusing because of type inference #79744