On Sat, 2019-06-01 at 17:14 +0300, Eduard-Mihai Burtescu wrote: > When libiberty/rust-demangle.c was initially added, its two exports, > rust_is_mangled and rust_demangle_sym, made it to include/demangle.h. > However, these two functions are merely implementation details of > cplus_demangle and rust_demangle, only the latter should be public. > > This is becoming a problem, because the new Rust mangling scheme > does not fit this "postprocess after C++ demangling" API at all, > so rust_demangle_sym would forever be stuck supporting only the > legacy mangling, whereas rust_demangle can easily handle both > (the new version of which I plan to upstream soon). > > I'm hoping that libiberty doesn't have strict backwards-compat > requirements, so that we can hide these two functions. > Also, as far as I'm aware, nobody is using them in the wild.
valgrind uses an embedded copy of the libiberty demangler (slightly changed to use valgrind's internal memory allocation scheme) which does use these functions directly: https://sourceware.org/git/?p=valgrind.git;a=blob;f=coregrind/m_demangle/demangle.c;hb=HEAD#l153 But we could of course just include the "private" header instead, when we next sync up with libiberty. We use these functions directly precisely because the rust demangling scheme is (currently) based on top of the traditional _Z C++ demangling scheme and we know that it will be done "in place". If there is a new Rust demangling scheme that doesn't have that property we'll have to adopt to a different demangling scheme in the future. Any help with that appreciated. valgrind has been useful for combined c/c++/rust programs. Cheers, Mark
