This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] libiberty: Add Rust symbol demangling.
On Fri, Nov 11, 2016 at 8:32 AM, Mark Wielaard <mark@klomp.org> wrote:
> On Fri, 2016-11-11 at 07:01 -0800, Ian Lance Taylor wrote:
>
>> Are you completely confident that Rust mangling will never change to
>> start requiring more space in the demangled string? If that could
>> ever happen, you have chosen an unfortunate API.
>
> For now, while being based on gnu_v3, yes it will be. And that is really
> what the two new interfaces rust_is_mangled () and rust_demangle_sym ()
> are about. You would only use them if you already know the symbol is
> gnu_v3 mangled and might have the "special rust flavor".
>
> But I expect people normally don't care about the specific mangling
> scheme used and would just use rust_demangle () or the more generic
> cplus_demangle () which can evolve to support any underlying mangling
> scheme. And those really should be used for new code.
>
> If there are libiberty interface stability issues then we could drop
> rust_is_mangled () and rust_demangle_sym () from demangle.h. But I do
> think they are useful for how people currently demangle rust symbols (or
> if they just need a filter over __cxa_demangle).
If these functions may only work "for now" as you say above, then it
seems that they need to be documented as "WARNING: this function may
stop working in the future." And if we need to add that warning, and
if most people are going to use rust_demangle anyhow, and if new code
should rust_demangle anyhow, then I don't see why we should declare
these functions in demangle.h. I don't feel especially strongly about
this, but it seems a bit weird to add an API that may break
irreparably.
Ian