Hi all. Sorry if this is the wrong forum category, etc.—this is my first post here.
Easy access to demangling is provided by libSwiftDemangle, but the exposed functions only support turning a mangled string into a demangled string. I see that under the hood, this uses more expressive APIs which turn a mangled name into a more expressive, tree-like structure.
I would like to use this API in my own application, preferably without building the entire Swift source tree.
In a smaller CMake project, one might configure the project then explicitly build a single target, letting the underlying build system worry about the dependencies, etc.—I have done this many times before.
However, I am a bit overwhelmed by build-script—and have struggled to sidestep it entirely, by configuring CMake myself—and am wondering how I might accomplish building just a single library (presumably swiftDemangling) and its dependencies so that I may use it in another project.
I understand this is probably not a high-priority issue (nor a supported use case), but any wisdom on this subject would be appreciated.
It looks like it's build separately as libSwiftDemangling.a, a library that's then used as part of the runtime, compiler, and libSwiftDemangler.{dylib,so,dll}. The demangling code is intended to be fairly isolated from the rest of the compiler source, because it's reused in all of these different contexts already, so instead of wrangling with our build system, you might have better success pulling it out into a separate project, along with the few headers it needs, and building it independently.
I also had this idea originally and wrote it off as I figured I'd end up playing "whack-a-mole" with dozens of compiler and linker errors...
To my surprise, I did actually get this to work. I created a standalone CMake project that grafts headers from the Swift source tree and links against LLVM from Homebrew. Everything works just fine as far as I can tell.
The demangler would be a good candidate for rewriting into Swift. It could benefit from a more expressive API that was callback-based, with the tree construction as one of the possible clients, but also allowing direct implementation of walkers that don't allocate intermediate structure.
Indeed. The tree structure is also more reflective of the "old mangling", for compatibility with the debugger, and we have to do some contortions to build it that way, then undo those contortions in other parts of the runtime.
I'm using it from C++ code, so the demangler being written in C++ is actually feature for me. That being said, obviously my use case is not the one to optimize for. If it were rewritten in Swift, having string- and tree-form demangling plumbed through a C API would definitely be nice.
Although I think I recall seeing a post this morning about Swift and C++ interop developments...