On nightly rustc, E0599 emits a massive diagnostic to suggest wrapping the receiver in every combination of {Box,Pin,Rc,Arc}::new({,&,&mut} expr)

[PatchMixolydic]

Given the following code (playground):

trait Bar {}
impl Bar for String {}

fn main() {
  let s = String::from("hey");
  let x: &dyn Bar = &s;
  x.as_ref();
}

The output on 1.53.0-nightly (2021-04-29 478a07df05e3fe8df964) is:

Long diagnostic

error[E0599]: the method `as_ref` exists for reference `&dyn Bar`, but its trait bounds were not satisfied
   --> src/main.rs:7:5
    |
1   | trait Bar {}
    | --------- doesn't satisfy `dyn Bar: AsRef<_>`
...
7   |   x.as_ref();
    |     ^^^^^^ method cannot be called on `&dyn Bar` due to unsatisfied trait bounds
    |
    = note: the following trait bounds were not satisfied:
            `dyn Bar: AsRef<_>`
            which is required by `&dyn Bar: AsRef<_>`
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Box::new(x).as_ref();
    |   ^^^^^^^^^ ^
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Pin::new(x).as_ref();
    |   ^^^^^^^^^ ^
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Arc::new(x).as_ref();
    |   ^^^^^^^^^ ^
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Rc::new(x).as_ref();
    |   ^^^^^^^^ ^
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Box::new(&mut x).as_ref();
    |   ^^^^^^^^^^^^^  ^
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Pin::new(&mut x).as_ref();
    |   ^^^^^^^^^^^^^  ^
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Arc::new(&mut x).as_ref();
    |   ^^^^^^^^^^^^^  ^
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Rc::new(&mut x).as_ref();
    |   ^^^^^^^^^^^^  ^
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Box::new(&x).as_ref();
    |   ^^^^^^^^^^ ^
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Pin::new(&x).as_ref();
    |   ^^^^^^^^^^ ^
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Arc::new(&x).as_ref();
    |   ^^^^^^^^^^ ^
help: consider wrapping the receiver expression with the appropriate type
    |
7   |   Rc::new(&x).as_ref();
    |   ^^^^^^^^^ ^

Box, Pin, Arc, and Rc are suggested three times each: once for x, once for &x, and once for &mut x. I'm not sure if this is a problem, but this seems incredibly verbose to me.

Note that the output on stable 1.51 and beta 1.52 is different:

error[E0599]: the method `as_ref` exists for reference `&dyn Bar`, but its trait bounds were not satisfied
 --> src/main.rs:7:5
  |
1 | trait Bar {}
  | --------- doesn't satisfy `dyn Bar: AsRef<_>`
...
7 |   x.as_ref();
  |     ^^^^^^ method cannot be called on `&dyn Bar` due to unsatisfied trait bounds
  |
  = note: the following trait bounds were not satisfied:
          `dyn Bar: AsRef<_>`
          which is required by `&dyn Bar: AsRef<_>`
  = help: items from traits can only be used if the trait is implemented and in scope
  = note: the following trait defines an item `as_ref`, perhaps you need to implement it:
          candidate #1: `AsRef`

[PatchMixolydic]

My mistake, each repetition is actually different in that two suggest taking a reference to x:

7   |   Box::new(x).as_ref()
7   |   Box::new(&x).as_ref()
7   |   Box::new(&mut x).as_ref()

This still seems like a fairly massive diagnostic, though. I've updated the original post in light of this. Feel free to close if a diagnostic of this size is fine here.

[Aaron1011]

cc @estebank

[PatchMixolydic]

Might be a duplicate of #84272, or at least fixed by the same PR that fixed it

[workingjubilee]

Even if it was considered reasonable to suggest each and every possible type combination, there is no pressing reason for it to generate the intervening lines as well: rustc is a compiler, not a can of spam. This remains unpatched on nightly, and is thus a stable-to-beta diagnostic regression.

[camelid]

This remains unpatched on nightly, and is thus a stable-to-beta diagnostic regression.

AFAICT, this is not present on beta, and is only present on nightly, so it's a stable-to-nightly regression. Please correct me if I misunderstood!

[steffahn]

searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24
regressed nightly: nightly-2021-04-09
searched commits: from 361bfce to 2e495d2
regressed commit: 2118526

That is:

Rollup of 5 pull requests

Successful merges:

 - #82497 (Fix handling of `--output-format json` flag)
 - #83689 (Add more info for common trait resolution and async/await errors)
 - #83952 (Account for `ExprKind::Block` when suggesting .into() and deref)
 - #83965 (Add Debug implementation for hir::intravisit::FnKind)
 - #83974 (Fix outdated crate names in `rustc_interface::callbacks`)

so it’s #83689. I guess @estebank has already been mentioned.

@rustbot label D-verbose

[estebank]

Yes, yes, I introduced this regression. Mea culpa, everybody. In my defense I keep flip-flopping between being too restrictive and too permissive for new suggestions and someone always ends up getting the short end of the stick. This week, I'm leaning towards "too permissive" and if the suggestion triggers too often, then detect the cases and make it more constrained, because the alternative is that the suggestion isn't shown when it could, and we'll never find out. This is IMO better, as long as regressions are caught in nightly, like it was in this case.</rant>

Anyways, #84808 fixes this.

[JohnTitor]

Assigning P-high as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

[pietroalbini]

This now affects 1.53.0 beta. Updating the labels accordingly.

[pietroalbini]

Still needs to be backported.

[apiraino]

@pietroalbini @Mark-Simulacrum the beta backport for patch #84808 was approved, can this now be closed?

[Mark-Simulacrum]

I think we should wait until it actually lands onto beta

[estebank]

This was merged in beta already, right? #84996

[Mark-Simulacrum]

Ah, so it was.