[Returned for revision] SE-0262: Demangle function

The core team supports having standardized functionality for turning a Swift symbol name into a human-readable string for logging, debugging, and crash reporting purposes. However, many important design points were raised in the review of SE-0262 Demangle Function, and so we are returning the proposal for revision.

  • A lot of the discussion explored the details of the unsafe buffer-based API, which was offered as a means of accessing the demangler in a limited runtime context, such as a crashed process or a signal handler. However, the current demangler implementation is not suitable for such applications, because even if it were given a preallocated output buffer for the returned string, it still freely allocates in the course of parsing the mangling and forming the parse tree for it. Presenting an API that might seem safe for use in contexts that can't allocate would be misleading at this point, so the core team recommends dropping the unsafe variants from the proposal, leaving only the (String) -> String? variant.
  • Jordan Rose raised the questions of what specific use cases this API is intended for, and what variation of demangling output it uses. The core team believes that the use cases for this API are clear—the aforementioned cases of logging for diagnostic purposes. However, the proposal should consider what form of demangling output the API generates. The core team recommends supporting at least the "simplified" form (used by lldb, Instruments, and similar tools by default, or swift-demangle -simplified) and the full form (used by swift-demangle's default mode).
  • Brent Royal-Gordon raised the concern of polluting the global namespace with a relatively niche, low-level function. Independent of this proposal, the Core Team would be interested in starting discussion of a "Runtime" module, akin to <objc/runtime.h> in Objective-C or libc++abi, that provides access to low-level functionality and data structures in the Swift runtime that can be used for reflection and diagnostic purposes but should not be part of the standard library. The Core Team thinks that the proposed demangle function makes sense as a standalone, top-level function. However, it would be a natural candidate for such a Runtime module if it existed.

Thank you to everyone who participated in the review!

Joe Groff
Review Manager


Did this proposal ever get revised, Joe? I did a search, and it seems like this is where it stopped.

Gosh I could use a built-in demangler.


I don't believe so. If you need a demangler today, the implementation in the compiler should be fairly well-isolated from the rest of the compiler and runtime, by necessity of having to be used in both, so you could build the libswiftDemangle library and link it into your project yourself.

1 Like

Oh that's a shame. Thanks for the recommendation — I've been using Matt Gallagher's CwlDemangle, and that's working fine - it'd just be nice to have this built-in to the language.

1 Like

Since the issues preventing it from being accepted weren't all that big, so if you're interested perhaps you could revive the proposal @tonyarnold ? If needed, I'd be happy to provide guidance.

Yeah, that sounds like a great way I could contribute - I'd appreciate the guidance, too!


I tried to use "_swift_stdlib_demangle" but surprisingly that wasn't so easy to compile, so ended up using the mentioned single file CwlDemangle, which compiled straight away and seems to work fine. Now I have the file name and the function name, but how do I get the corresponding line number? (can work in debug build only if needed).

The C function swift_demangle is the ABI entry point, IIRC.


Thank you. I managed to guess its signature right:

char* swift_demangle(char* mangledName, size_t mangledNameLen, char* outputBuffer, size_t* outputBufLen, int32_t flags);

No idea what to pass in flags, passing 0.

The only thing left is to get the line number, any idea?

The line number is only contained in debug symbols, so I guess you have to extract and interpret the dwarf tables.

You may get some info in this video: Symbolication: Beyond the basics - WWDC21 - Videos - Apple Developer

The atos command line tool can provide you this information, so maybe invoking it and parsing its output may be an option.


Debug only is ok... although I'd still wonder how Xcode can do it in release builds: you can still step through the code (albeit somewhat erratically) so there must be some "line number" <-> "address" correspondence available to it in release builds.

Because by default, Xcode generates debug symbols for release build (in a separated .dsym bundle).

cwldemangle hasn't been updated in approximately 2 years. has swift mangling changed significantly since then?

has it changed? yes. does the mangling that it does support still work? probably, maybe? there certainly have been a lot of additions to the mangling.

I've been using the code below. The swift_demangle runtime entry point doesn't seem to have changed for years and tracks new Swift features.

Yeah, that function just invokes the actual demangler who is up to date. Also, keep in mind this function has the C calling convention and @_silgen_name imports as the Swift calling convention. You need to define this function in a C header and have that be imported to have the correct calling convention.


that function only returns a human-readable string description of the mangled name. it’s not very useful for getting semantic information about the symbol, see discussion here

It works though, I use it extensively in the InjectionIII app. This is because the Swift and C ABIs align for the types used. It would perhaps be handy if this were taken further to a rich Meta-data api able to represent argument name, types etc but this can be used a starting point.

The API as it stands is enough for what I use it for (showing Swift types in the UI of Reveal). I understand that there might be a desire for more information from a new API, but for now this seems pretty good?

I've started updating the proposal and the implementation with some guidance from @ktoso - hopefully I'll have something ready for comment and review after WWDC.

1 Like