Point at correct argument when async fn output type lifetime disagrees with sign...

tmandry commented on Dec 22, 2021

Fixes most of #74256.

Problems fixed

This PR fixes a couple of related problems in the error reporting code.

Highlighting the wrong argument

First, the error reporting code was looking at the desugared return type of an async fn to decide which parameter to highlight. For example, a function like

async fn async_fn(self: &Struct, f: &u32) -> &u32
{ f }

desugars to

async fn async_fn<'a, 'b>(self: &'a Struct, f: &'b u32)
-> impl Future<Output = &'a u32> + 'a + 'b
{ f }

Since f: &'b u32 is returned but the output type is &'a u32, the error would occur when checking that 'a: 'b.

The reporting code would look to see if the "offending" lifetime 'b was included in the return type, and because the code was looking at the desugared future type, it was included. So it defaulted to reporting that the source of the other lifetime 'a (the self type) was the problem, when it was really the type of f. (Note that if it had chosen instead to look at 'a first, it too would have been included in the output type, and it would have arbitrarily reported the error (correctly this time) on the type of f.)

Looking at the actual future type isn't useful for this reason; it captures all input lifetimes. Using the written return type for async fn solves this problem and results in less confusing error messages for the user.

This isn't a perfect fix, unfortunately; writing the "manually desugared" form of the above function still results in the wrong parameter being highlighted. Looking at the output type of every impl Future return type doesn't feel like a very principled approach, though it might work. The problem would remain for function signatures that look like the desugared one above but use different traits. There may be deeper changes required to pinpoint which part of each type is conflicting.

Lying about await point capture causing lifetime conflicts

The second issue fixed by this PR is the unnecessary complexity in try_report_anon_anon_conflict. It turns out that the root cause I suggested in #76547 (comment) wasn't really the root cause. Adding special handling to report that a variable was captured over an await point only made the error messages less correct and pointed to a problem other than the one that actually occurred.

Given the above discussion, it's easy to see why: async fns capture all input lifetimes in their return type, so holding an argument across an await point should never cause a lifetime conflict! Removing the special handling simplified the code and improved the error messages (though they still aren't very good!)

Future work

• Fix error reporting on the "desugared" form of this code
• Get the suggest_adding_lifetime_params suggestion firing on these examples
  • cc #42703, I think

r? @estebank