Skip to content

rustc: Error messages feel like they're backwards #53965

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

Closed
rusty-objects opened this issue Sep 5, 2018 · 4 comments
Closed

rustc: Error messages feel like they're backwards #53965

rusty-objects opened this issue Sep 5, 2018 · 4 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-frontend Area: Compiler frontend (errors, parsing and HIR) WG-diagnostics Working group: Diagnostics

Comments

@rusty-objects
Copy link

This code snippet illustrates a problem I've always had with the Rust compiler's error messages:

use std::ops::Deref;

fn foo<Inner: Deref<Target=[u8]>, Outer: Deref<Target=[Inner]>>(buf: Outer) {}

pub fn main() {
    let data = [0_u8];
    foo(&&[&data]);
}

The compiler error is:

error[E0271]: type mismatch resolving `<&&[&[u8; 1]; 1] as std::ops::Deref>::Target == [_]`
 --> src/main.rs:7:5
  |
7 |     foo(&&[&data]);
  |     ^^^ expected reference, found slice
  |
  = note: expected type `&[&[u8; 1]; 1]`
             found type `[_]`
note: required by `foo`
 --> src/main.rs:3:1
  |
3 | fn foo<Inner: Deref<Target=[u8]>, Outer: Deref<Target=[Inner]>>(buf: Outer) {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Intuitively, for me, found and expected are swapped. I expect the function to be the point of reference, and therefore the expected value and I expect the call site to be the candidate, and therefore the found value. However it seems reverse. Above you can see the expected type is the call site's &[&[u8; 1]; 1] and the found type is the function's [_]. I this often slows me down when chasing compile errors as I have to stop and mentally reverse my perception about expected and found.

I hesitate to call this a bug, as I think it's a matter of opinion. But it does feel the opposite of intuitive for me.

$ rustc --version
rustc 1.28.0 (9634041f0 2018-07-30)
@rusty-objects rusty-objects changed the title rustc: Error messages feel backwards rustc: Error messages feel like they're backwards Sep 5, 2018
@Centril Centril added A-frontend Area: Compiler frontend (errors, parsing and HIR) A-diagnostics Area: Messages for errors, warnings, and lints WG-diagnostics Working group: Diagnostics labels Sep 7, 2018
@Centril
Copy link
Contributor

Centril commented Sep 7, 2018

Not a bug; but I agree that it should be swapped.

@atorstling
Copy link

atorstling commented Dec 27, 2018

I agree. Came here to report the same type of confusing error message for this code:

#![feature(trait_alias)]

trait F8 = FnOnce() -> u8;

fn higher<T: F8>(t: T) -> u8 {
    t()
}

fn main() {
    higher(|| 3u16);
}

This yields:

higher(|| 3u16);
   |     ^^^^^^ expected u16, found u8

@Centril
Copy link
Contributor

Centril commented Dec 27, 2018

cc @estebank

@estebank
Copy link
Contributor

Current output:

error[E0271]: type mismatch resolving `<&&[&[u8; 1]; 1] as std::ops::Deref>::Target == [_]`
 --> src/main.rs:7:5
  |
3 | fn foo<Inner: Deref<Target=[u8]>, Outer: Deref<Target=[Inner]>>(buf: Outer) {}
  |    ---                                         -------------- required by this bound in `foo`
...
7 |     foo(&&[&data]);
  |     ^^^ expected slice, found `&[&[u8; 1]; 1]`
  |
  = note: expected slice `[_]`
              found type `&[&[u8; 1]; 1]`
error[E0271]: type mismatch resolving `<[closure@src/main.rs:10:12: 10:19] as std::ops::FnOnce<()>>::Output == u8`
  --> src/main.rs:10:5
   |
5  | fn higher<T: F8>(t: T) -> u8 {
   |    ------    -- required by this bound in `higher`
...
10 |     higher(|| 3u16);
   |     ^^^^^^ expected `u8`, found `u16`

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 A-frontend Area: Compiler frontend (errors, parsing and HIR) WG-diagnostics Working group: Diagnostics
Projects
None yet
Development

No branches or pull requests

4 participants