This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] libiberty: Add Rust symbol demangling.


On Fri, 2016-11-11 at 07:01 -0800, Ian Lance Taylor wrote:
> On Thu, Nov 3, 2016 at 10:39 AM, Mark Wielaard <mark@klomp.org> wrote:
> >
> > include/ChangeLog:
> >
> > 2016-11-03  David Tolnay <dtolnay@gmail.com>
> >            Mark Wielaard  <mark@klomp.org>
> >
> >        * demangle.h (DMGL_RUST): New macro.
> >        (DMGL_STYLE_MASK): Add DMGL_RUST.
> >        (demangling_styles): Add dlang_rust.
> >        (RUST_DEMANGLING_STYLE_STRING): New macro.
> >        (RUST_DEMANGLING): New macro.
> >        (rust_demangle): New prototype.
> >        (rust_is_mangled): Likewise.
> >        (rust_demangle_sym): Likewise.
> >
> > libiberty/ChangeLog:
> >
> > 2016-11-03  David Tolnay <dtolnay@gmail.com>
> >            Mark Wielaard  <mark@klomp.org>
> >
> >        * Makefile.in (CFILES): Add rust-demangle.c.
> >        (REQUIRED_OFILES): Add rust-demangle.o.
> >        * cplus-dem.c (libiberty_demanglers): Add rust_demangling case.
> >        (cplus_demangle): Handle RUST_DEMANGLING.
> >        (rust_demangle): New function.
> >        * rust-demangle.c: New file.
> >        * testsuite/Makefile.in (really-check): Add check-rust-demangle.
> >        (check-rust-demangle): New rule.
> >        * testsuite/rust-demangle-expected: New file.
> 
> 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).

> Has David Tolnay signed the FSF copyright agreement?  I don't see him
> on the list.
> 
> Other than that, this patch looks OK.

Thanks. I'll wait till David's paperwork clears before committing.

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]