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!
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.
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.
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.
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).
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.
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.