Less unused argument spew

[DanielKeep]

Unused arguments are attached to the main error as labels. This drops
the traditional named/positional message split (except in the case of a
single unused argument) for "unused" in interest of terseness.

Closes#37718.

---

I tried using MultiSpan with struct_err_span, but none of the spans were emitted. This was also the case with trying to attach a MultiSpan to the Diagnostic as a note. span_label was the only seemingly relevant method I found that would actually display.

It feels a bit ugly, but works.

I also chose to merge the two branches for how to display the error for the sake of simplifying and unifying the diagnostic construction a little.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (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.

[brson]

The remaining three cases in this diff all ended up bigger! Can they be special cased back to the old way?

[brson]

Looks good. Can you add a test case with a multi-line span so we can see what it looks like?

[DanielKeep]

I reverted the change to the single missing argument case, so it's back to the way it was. I also added a multi-line macro invocation to show what that looks like.

The Travis failure appears to be unrelated to these changes: something about a lock file while it was setting up for the build.

[estebank]

@DanielKeep FYI, I believe MultiSpans are accepted by all the span_* methods now.

BTW, this looks great!

[steveklabnik]

The Travis failure appears to be unrelated to these changes: something about a lock file while it was setting up for the build.

I've re-queued Travis. @brson are you happy with this PR now, assuming it passes?

[alexcrichton]

Sorry for the delay here @DanielKeep! It looks like the UI test may be failing on Travis though? If you want to rebase, fix tests, and ping me I'll r+

[mrhota]

@DanielKeep ping?

[brson]

@bors r+

[bors]

📌 Commit 6f0ba7e has been approved by brson

[bors]

⌛ Testing commit 6f0ba7e with merge abed1ac...

[eddyb]

@brson see @alexcrichton's message, the UI test just doesn't pass.

@bors r-

[eddyb]

@bors force

[bors]

💔 Test failed - status-travis

[alexcrichton]

@bors: r=brson

[bors]

📌 Commit 6f0ba7e has been approved by brson

[alexcrichton]

@bors: retry

[frewsxcv]

There's a test failure here https://travis-ci.org/rust-lang/rust/jobs/176910049

[frewsxcv]

@bors r-

[estebank]

@DanielKeep@frewsxcv It looks like the test stderr output has to be updated to latest master, that's all.

[alexcrichton]

Closing due to inactivity, but feel free to resubmit with tests fixed!