Diagnostics: bad suggestion when I have wrong parentheses around a dyn trait pointer type

[RalfJung]

This code

trait Trait {}

fn assert_send(ptr: *mut dyn Trait) -> *mut dyn (Trait + Send) {
    ptr as _
}

produces the following error

error: incorrect braces around trait bounds
 --> src/lib.rs:3:49
  |
3 | fn assert_send(ptr: *mut dyn Trait) -> *mut dyn (Trait + Send) {
  |                                                 ^            ^
  |
help: remove the parentheses
  |
3 - fn assert_send(ptr: *mut dyn Trait) -> *mut dyn (Trait + Send) {
3 + fn assert_send(ptr: *mut dyn Trait) -> *mut dyn  Trait + Send {
  |

error: could not compile `playground` (lib) due to previous error

First of all, "braces" is the wrong word here I think, AFAIK "braces" means {...}, but here we have parentheses.

More importantly though, if I apply the suggestion, the code still does not build! Instead it now shows a different error:

error: ambiguous `+` in a type
 --> src/lib.rs:3:45
  |
3 | fn assert_send(ptr: *mut dyn Trait) -> *mut dyn Trait + Send {
  |                                             ^^^^^^^^^^^^^^^^ help: use parentheses to disambiguate: `(dyn Trait + Send)`

The correct syntax is to write *mut (dyn Trait + Send).

[estebank]

FWIW, I consider it ok if suggestions give you incomplete suggestions as long as subsequent errors close the gap (as it these errors do). In some cases making the initial error have enough understanding to produce the correct suggestion can cause an explosion of complexity (and sometimes it is flat out impossible unless we made the compiler less stage based than it is now).

[RalfJung]

I felt somewhat mislead by the suggestion. The fix was simply to move the ( from after dyn to before dyn. But the compiler made me entirely remove the parentheses, only to then tell me to add them back in a different way.

But also more generally, I think any time there is a concrete suggestion like in the original issue, that suggestion must compile. Otherwise I'll stop trusting the compiler's suggestions and just ignore them -- it'll be quicker to look for the right fix directly than hunt a chain of compiler errors.