Handle desugaring in impl trait bound suggestion

wabain commented 10 days ago

Fixes #79843.

When an associated type of a generic function parameter needs extra bounds, the diagnostics may suggest replacing an impl Trait with a named type parameter so that it can be referenced in the where clause. On stable and nightly, the suggestion can be malformed, for instance transforming:

async fn run(_: &(), foo: impl Foo) -> std::io::Result<()>

Into:

async fn run(_: &, F: Foo(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send
                 ^^^^^^^^         ^                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Where we want something like:

async fn run<F: Foo>(_: &(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send
            ^^^^^^^^              ^                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^

The problem is that the elided lifetime of &() is added as a generic parameter when desugaring the async fn; the suggestion code sees this as an existing generic parameter and tries to use its span as an anchor to inject F into the parameter list. There doesn't seem to be an entirely principled way to check which generic parameters in the HIR were explicitly named in the source, so this commit changes the heuristics when generating the suggestion to only consider type parameters whose spans are contained within the span of the Generics when determining how to insert an additional type parameter into the declaration. (And to be safe it also excludes parameters whose spans are marked as originating from desugaring, although that doesn't seem to handle this elided lifetime.)