Repository navigation
Symbol-mangling (v0) should show difference between async / closure / generator #104830
Description
The following code:
pub async fn fn_with_nested_block() -> Backtrace {
None.unwrap_or_else(|| async { Backtrace::force_capture() })
.await
}Generates the following demangled symbol with legacy demangling:
async_codegen::fn_with_nested_block::{{closure}}::{{closure}}::{{closure}}
(v0 mangling is similar, but with {closure#0} instead)
Whereas Windows mangling gives this fn name:
async_codegen::fn_with_nested_block::async_fn$0::closure$0::async_block$0
This makes it clear what is an async fn, closure or async block. v0 symbol mangling should make a similar distinction.
#104333 is a first attempt to thread the necessary information through to the place that does the symbol mangling, but actually extending the v0 symbol mangling format / spec is necessary as well to fully solve this.
Activity
jyn514 commentedon Apr 12, 2023
v0 is a public spec that is already been implemented by other tools (e.g. gdb). is this proposed change backwards compatible? If not, is it enough to extend the tools or does there need to be a new v1 format?
sharnoff commentedon Jun 15, 2025
I hit this issue recently — I was digging into compile times for a project and having
{closure#0}in the v0 mangling of an async function led me to incorrectly believe that the compiler was spending a long time optimizing a small closure in the function, rather than the main body of the async function.Reading through this issue and the v0 mangling format (link for reference), there's two options that come to mind:
my_crate::my_fn::{shim:async_fn}::{closure#0}::{closure:async_block#0}my_crate::my_fn::{async_fn}::{closure#0}::{async_block#0}.async fnas a "shim" butasync { ... }as a unique namespace type. There's a few potential routes hereThe v0 spec does say to account for new tags being added, but it seems like the second route would still require a new version.
Maybe a reasonable path forward would be to use option (1) with the v0 format, but also start work on a v1 that allows option (2) ?
I'm not sure what the long-term path should be w.r.t. representing new language features in symbols — it'd be unfortunate if a wide swathe of tools need to be updated before each language feature, but including the block types as full identifiers in the symbol (e.g.
async_block?) is also a lot of extra characters.Either way, I'm happy to try picking up #104333 following option (1), if that'd be worthwhile?
kornelski commentedon Jun 27, 2025
The v0 spec already has names for closures, they're just set to an empty string by rustc.
I've checked that the C port supports this.