Include type of missing trait methods in error

[estebank]

Provide either a span pointing to the original definition of missing
trait items, or a message with the inferred definitions.

Fixes #24626. Follow up to PR #36371.

If PR #37369 lands, missing trait items that present a multiline span will be able to show the entirety of the item definition on the error itself, instead of just the first line.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[nikomatsakis]

@emilio would you mind converting the affected tests to ui tests? or at least some representative set? It's a bit hard for me to visualize the formatting currently =)

[estebank]

@nikomatsakis will do. Should I duplicate the tests, adding UI tests that match the current ones, or just replace the current tests with the new ones?

[nikomatsakis]

@estebank any tests you move to ui tests can be removed from compile-fail

[estebank]

@nikomatsakis I've moved the tests from compile-fail to ui.

[nikomatsakis]

Looks good @estebank -- think you could add a few more tests (see comments)?

[nikomatsakis]

Not related to this PR, I think, but this text "<FooConstForMethod as Foo>" seems pretty funny to me; I expect to see just Foo... is there an open issue on that?

[estebank]

After going through the open tickets, I don't think there's one for this, so I opened one.

[nikomatsakis]

Can you create a test case where the item from the other trait is a fn with a non-trivial signature?

Probably worth testing the constant case too.

[estebank]

Added test/run-make/missing-items covering all three cases.

[nikomatsakis]

Wait...why did you make it a run-make test? (Those are generally frowned upon, since they don't fit the usual scheme.) But in particular, this all seems like a good candidate for a ui test?

[estebank]

Duly noted, I didn't know they were frowned upon.

In order for this codepath to be executed the trait shouldn't have a span available, which as far as I know only happens when compiling against an extern crate. I hadn't noticed that test/ui/cross-crate-macro-backtrace does exactly that. I'll change this to a ui test.

[nikomatsakis]

@bors r+

[bors]

📌 Commit 40c2c0f has been approved by nikomatsakis

[nikomatsakis]

Nice work @estebank =)

[alexcrichton]

Hm looks like the run-make test here is failing on nightly, preventing nightlies.

Still investigating why.

[alexcrichton]

cc @brson

[pmarcelll]

I tried to reproduce what the Makefile does,

$ rustc m1.rs -C prefer-dynamic
$ rustc m2.rs

gives the folloving error:

error[E0463]: can't find crate for `m1`

So I thought it's a linking error. And indeed, rustc m2.rs -L ./ gives the right error message.

EDIT: Or the stuff in tools.mk should take care of this somehow?
EDIT2: The real error:

$ make
rustc m1.rs -C prefer-dynamic
rustc m2.rs -L ./ 2>&1 | grep "error\[E0046\]: not all trait items implemented, missing: .*"
error[E0046]: not all trait items implemented, missing: `CONSTANT`, `Type`, `method`
rustc m2.rs -L ./ 2>&1 | grep "  --> m2.rs:18:1"
  --> m2.rs:18:1
rustc m2.rs -L ./ 2>&1 | grep "   | ^ missing .CONSTANT., .Type., .method. in implementation"
   | ^ missing `CONSTANT`, `Type`, `method` in implementation
rustc m2.rs -L ./ 2>&1 | grep "   = note: .CONSTANT. from trait: .const CONSTANT: u32;."
make: *** [Makefile:8: all] Error 1

The note is missing.