Do not include implicit desugared closure from async fn in closure type path

[estebank]

Make the path of items within an async fn, including the implicit async closure it desugars to not include the {closure#0} path segment. So async fn foo::{closure#0} gets rendered as foo instead in diagnostics. This only affects the pprinter used for diagnostics, the implicit closure is still included in symbol mangling. End users should not need to be exposed to the inner workings of async desugaring in normal circumstances.

Noticed while looking at #144337 / https://internals.rust-lang.org/t/post-0/23184 to modify the closure rendering without paths. Changing the test runner to use -Zspan_free_formats showed many cases where the previous rendering for async functions was quite confusing, particularly for those that had closures within them.

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[compiler-errors]

I think this change is detrimental to understanding the actual structure of the desugared program. The reality here is that there are two items, async_function and async_function::{closure#0}. We really should keep distinguishing them.

Especially because the only changes are in mir-opt outputs and rustc_force_inline, which is currently a non-stable feature -- my understanding is that we could improve the diagnostics for that by improving the messaging in that case.

[compiler-errors]

If you are dissatisfied with the output of -Zspan_free_formats, I think that should probably be doing work to not rely so heavily on the def path rendering of items, since closures are definitely not the only case where we'll print out confusing def paths with ::{something}::-like segments.

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[RalfJung]

Make the path of items within an async fn, including the implicit async closure it desugars to not include the {closure#0} path segment. So async fn foo::{closure#0} gets rendered as foo instead in diagnostics.

So this means we'll have two foo in the MIR dump that will be impossible to distinguish? That seems like a problem, no?

[rust-log-analyzer]

The job aarch64-gnu-llvm-19-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [codegen-units] tests/codegen-units/item-collection/closures.rs stdout ----

These items should have been contained but were not:

MONO_ITEM fn async_fn::{closure#0} @@


FATAL: !(missing.is_empty() && unexpected.is_empty() && wrong_cgus.is_empty())

thread '[codegen-units] tests/codegen-units/item-collection/closures.rs' panicked at src/tools/compiletest/src/runtest/codegen_units.rs:103:13:
fatal error
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace