Reword E0277 default error message

[estebank]

error[E0277]: the trait `Copy` is not implemented for `X`
  --> $DIR/trait-impl-bound-suggestions.rs:14:52
   |
LL |     fn return_the_constrained_type(&self, x: X) -> ConstrainedStruct<X> {
   |                                                    ^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `X`

[rustbot]

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[estebank]

Zulip thread for t-types to chime in at

r? @oli-obk

[compiler-errors]

Do you mind adding a fleshed out PR description that explains the motivation for this change? And also what it actually implements alongside the main message reordering, like erasing lifetimes from the predicate?

For example, I assume that you're erasing lifetimes because you were getting split-up binders in error messages like "the trait for<'a> Foo was not implemented for &'a Bar"? It would be nice to actually know what motivated that change -- because if it was just for aesthetic purposes, then maybe it's best to separate that out into separable PR for future git-blames and tweaks on error reporting w/ binders.

In general, over-documenting rather than under-documenting is probably best for those who are exploring past PRs, and right now the PR is a bit light on the wording, especially given its size.

[estebank]

@compiler-errors FWIW, I opened the PR for the benefit of the zulip chat conversation (which sadly ended up going to discuss an separate topic that I made the mistake of raising on the same thread) with the anticipation that the feedback might require many further changes to this code. I assigned to @oli-obk because we had been talking about making this change and needing input from t-types, so I knew he wouldn't r+ it until that conversation happened. I should probably have opened it as a draft PR.

[estebank]

@compiler-errors I need to edit the commit descriptions, but I split the changes into independent commits so that you can see what each change affects in the output.

For example, I assume that you're erasing lifetimes because you were getting split-up binders in error messages like "the trait for<'a> Foo was not implemented for &'a Bar"? It would be nice to actually know what motivated that change -- because if it was just for aesthetic purposes,

That's what originally caught my attention, but as I was looking at it I noticed that the flat out removal of lifetimes made the message read clearer without too much lost information. This might be different if the only reason a bound failed was due to outlives restrictions, which we could handle independently. Another thing that would be nice not to lose would be 'static bounds on types that with the current blatant erasure we do.

[bors]

☔ The latest upstream changes (presumably #121890) made this pull request unmergeable. Please resolve the merge conflicts.

[apiraino]

this patchset needs a rebase

@rustbot author