Change:
Given the following code (): The output on is: <details<summaryLong diagnostic</summary</details, , , and are suggested three times each: once for , once for , and once for . 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:
My mistake, each repetition is actually different in that two suggest taking a reference to : 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.
cc
Might be a duplicate of , or at least fixed by the same PR that fixed it
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.
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!
searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-09 searched commits: from to regressed commit: That is: so it’s . I guess has already been mentioned. label D-verbose
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.&lt;/rantAnyways, fixes this.
Assigning and removing .
This now affects 1.53.0 beta. Updating the labels accordingly.
Still needs to be backported.
the beta backport for patch was approved, can this now be closed?
I think we should wait until it actually lands onto beta
This was merged in beta already, right?
Ah, so it was.

Discussion:
} let mut restrict_type_params = false; <ins> let mut unsatisfied_bounds = false; </ins> if !unsatisfied_predicates.is_empty() { let def_span = |def_id| { self.tcx.sess.source_map().guess_head_span(self.tcx.def_span(def_id))

err.note(&format!( "the following trait bounds were not satisfied:n{bound_list}" )); <ins> unsatisfied_bounds = true; </ins> } }

source, out_of_scope_traits, &unsatisfied_predicates, <ins> unsatisfied_bounds, </ins> ); }

source: SelfSource<'tcx>, valid_out_of_scope_traits: Vec<DefId>, unsatisfied_predicates: &[(ty::Predicate<'tcx>, Option<ty::Predicate<'tcx>>)], <ins> unsatisfied_bounds: bool, </ins> ) { let mut alt_rcvr_sugg = false; <del> if let SelfSource::MethodCall(rcvr) = source { </del> <ins> if let (SelfSource::MethodCall(rcvr), false) = (source, unsatisfied_bounds) { </ins> debug!(?span, ?item_name, ?rcvr_ty, ?rcvr); let skippable = [ self.tcx.lang_items().clone_trait(),

h.finish() //~ ERROR no method named `finish` found for struct `DefaultHasher` } <del> fn main() {} </del> <ins> trait Bar {} impl Bar for String {} fn main() { let s = String::from("hey"); let x: &dyn Bar = &s; x.as_ref(); //~ ERROR the method `as_ref` exists for reference `&dyn Bar`, but its trait bounds } </ins>

LL | use std::hash::Hasher; | <del> error: aborting due to previous error </del> <ins> error[E0599]: the method `as_ref` exists for reference `&dyn Bar`, but its trait bounds were not satisfied --> $DIR/import-trait-for-method-call.rs:15:7 | LL | trait Bar {} | --------- doesn't satisfy `dyn Bar: AsRef<_>` ... LL |     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` error: aborting due to 2 previous errors </ins> For more information about this error, try `rustc --explain E0599`.