Change:
This example: gives this error: It took me some time to puzzle out what was happening here: expands to the default from the impl however is the impl method is accepted because it is more general than the trait definition but it fails to recursively invoke The error message without NLL, of course, is also not very illuminating.
Assigning myself to bookmark.
This seems to be a persistent ergonomics wart where traits get evaluated to (happens as well with returning and others I can't remember now) where it isn't expected. It is a bit sad, and we can improve the diagnostic errors, but I'm worried we'll be unable to preempt all the cases from being caught by accurate diagnostics, pushing people away from deeply nested structures. Maybe that is for the best, though.
I just want to note that the use of is, I think, a red herring in terms of the complaint about the diagnostic here. That is, I get the exact same diagnostic even if I add an explicit binder to the method, and then one can remove the . This is relevant because it means that if that feature is a red herring, then this bug may be relevant to the 2018 edition.
discussed with . We agreed this is not a blocker for 2018 edition. Tagging with NLL-deferred so it does not clog up our triage process.
I forgot to actual test how migration-mode (enabled for the 2018 edition) compares to . <detailsCurrent (nightly) 2018 edition output (): Current (nightly) output with (): </details
As for this week's triage, tagging this as P-medium priority.
I recently landed some changes ( and ) that are tangentially related to this but a similar strategy to them could be applied to this case.
Since feature has been removed, can this issue be closed as obsolete?
The example without : The error message isn't the same as migrate mode, but is on-par in terms of information (pointing out that the anonymous lifetime doesn't live as long as ). This issue can be closed by adding the above as a test.

Discussion:
<ins> // Regression test for #54779, checks if the diagnostics are confusing. #![feature(nll)] trait DebugWith<Cx: ?Sized> { fn debug_with<'me>(&'me self, cx: &'me Cx) -> DebugCxPair<'me, Self, Cx> { DebugCxPair { value: self, cx } } fn fmt_with(&self, cx: &Cx, fmt: &mut std::fmt::Formatter<'_>) -> std::fmt::Result; } struct DebugCxPair<'me, Value: ?Sized, Cx: ?Sized> where Value: DebugWith<Cx>, { value: &'me Value, cx: &'me Cx, } trait DebugContext {} struct Foo { bar: Bar, } impl DebugWith<dyn DebugContext> for Foo { fn fmt_with( &self, cx: &dyn DebugContext, fmt: &mut std::fmt::Formatter<'_>, ) -> std::fmt::Result { let Foo { bar } = self; bar.debug_with(cx); //~ ERROR: lifetime may not live long enough Ok(()) } } struct Bar {} impl DebugWith<dyn DebugContext> for Bar { fn fmt_with( &self, cx: &dyn DebugContext, fmt: &mut std::fmt::Formatter<'_>, ) -> std::fmt::Result { Ok(()) } } fn main() {} </ins>

<ins> error: lifetime may not live long enough --> $DIR/issue-54779-anon-static-lifetime.rs:34:24 | LL |         cx: &dyn DebugContext, |             - let's call the lifetime of this reference `'1` ... LL |         bar.debug_with(cx); |                        ^^ cast requires that `'1` must outlive `'static` error: aborting due to previous error </ins>