Improve diagnostics for E0282

[ruuda]

The error message was misleading, so I adjusted it, and I also added the long diagnostics for this error (resolves one point in #24407).

I was unsure about how to phrase the error message. Is “generic parameter binding” the correct term for this?

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

I think throughout these examples it should be safe to leave off the _i32 annotation, right?

[ruuda]

Yes, but then the type of x: Vec<_> depends on the integer literal default, which is a feature interacting here that is not really related to the error. Maybe we could use an other type like char to avoid defaults altogether, but is there a good and simple way to get an iterator there that is not silly? (E.g. let v = vec!('a', 'b', 'c'); v.iter().collect::<Vec<_>>() seems like a silly example to me.)

[pnkfelix]

If you're still inclined to use something like char, there is the option of starting with a string and iterating over its chars, like this:

    const HELLO: &'static str = "hello";
    let v: Vec<_> = HELLO.chars().rev().collect();
    println!("v: {:?}", v);

[pnkfelix]

and if you did that, you could avoid talking about VecDeque; you could just say that Vec<char> and String are suitable candidates:

    const HELLO: &'static str = "hello";
    let s: String = HELLO.chars().skip(1).collect();
    println!("Bert says, {:?}", s);

[ruuda]

@pnkfelix Yes, that is much better!

[alexcrichton]

Awesome, thanks @ruud-v-a!

[nikomatsakis]

@bors rollup r+

[bors]

📌 Commit 414dfb1 has been approved by nikomatsakis

[nikomatsakis]

This looks nice.

[bors]

⌛ Testing commit 414dfb1 with merge a65d3f9...

[bors]

💔 Test failed - auto-mac-64-nopt-t

[pnkfelix]

@ruud-v-a with a change like this, you need to update the test suite to reflect the change to the expected error message.

I highly recommend you do a local make check-stage1-cfail to catch these, and maybe make check-stage1-cfail-full as well ...

[ruuda]

Thanks for the heads-up. I did run make check (on Windows), isn’t it supposed to run all tests? Anyhow, I updated the compile-fail tests and I am running the tests (on Linux) at the moment.

[pnkfelix]

maybe I misinterpreted the log files, but it certainly seemed like the compile-fail tests did need updating. If you did not see failures on a windows make check, then that is quite troubling...

[ruuda]

@pnkfelix It were definitely those tests that failed. To be sure, I ran make check on 414dfb1 on my Windows box again. There were indeed failures, I missed them the first time. I did see ... FAILED scroll by this time, but the check does not stop on failure. The last few lines of output are these:

test [run-pass] run-pass/xcrate-unit-struct.rs ... ok
test [run-pass] run-pass/zero-size-type-destructors.rs ... ok
test [run-pass] run-pass/zero_sized_subslice_match.rs ... ok

test result: ok. 2034 passed; 0 failed; 33 ignored; 0 measured

make: *** wait: No child processes.  Stop.

Last time I only checked the last line, and I assumed 0 failed meant everything was good. The summary of compile-fail turned out to be hidden 2000 lines earlier between the rest of the test output.

[pnkfelix]

hmm, okay, that is a little bit more comforting, but still a little worrisome. Maybe this is something going wrong with our return codes on Windows, causing the make to miss the fact that the run errored?

[pnkfelix]

@ruud-v-a now make tidy is failing. :)

[ruuda]

Now make tidy is happy again, but make check-stage1-cfail fails for the files that I linewrapped. What am I doing wrong? Edit: It is a different set of files that fails, I edited the wrong files. Edit 2: The rebase below should pass.

[pnkfelix]

@bors r+ 4b8098b rollup