[PATCH] D110576: [Demangle] Add support for D programming language

[David Blaikie via Phabricator via llvm-commits]

dblaikie added subscribers: jhenderson, rnk.
dblaikie added a comment.

In D110576#3034731 <https://reviews.llvm.org/D110576#3034731>, @dblaikie wrote:

> In D110576#3029264 <https://reviews.llvm.org/D110576#3029264>, @Geod24 wrote:
>
>> In D110576#3027009 <https://reviews.llvm.org/D110576#3027009>, @dblaikie wrote:
>>
>>> As with the Rust demangling (check the commit history, it was done earlier this year), I think this'd be easier to review if it were implemented incrementally - it'll be easier to spot the test coverage for each feature as it's added. Otherwise it's a lot of code to try to validate in one piece.
>>
>> I'll try to provide a bit more verbose background into the contribution:
>>
>> This is a port of libiberty's D demangler <https://github.com/gcc-mirror/gcc/blob/master/libiberty/d-demangle.c> as some comments mention, which was written by Iain Buclaw <https://github.com/ibuclaw>, the maintainer of GDC (GCC-based D compiler).
>> We have been in frequent communication with him before the project started and he has no issue with this code being used (and re-licensed) by LLVM. If any document / proof is needed on that side, please let us know.
>> As the code is part of libiberty, it is the backbone used to demangle D symbols in binutils since v2.25 (released 2014-12-23, see https://forum.dlang.org/thread/rvoqllpimfskvlabprot@forum.dlang.org for the D-targeted announcement) and GDB.
>>
>> As such, we're also pretty confident that it is quite robust and covers most, if not all, of D feature. As Luis mentioned, if breaking it down is unavoidable for the purpose of moving forward, then it will be, but that sounds counter-productive.
>>
>> As for me, I am Luis' mentor during his Symmetry Autumn of Code <https://dlang.org/blog/2021/08/30/saoc-2021-projects/> time (a program similar to Google Summer of Code). The rough milestones / description of the project is also available here <https://github.com/dlang/projects/issues/81>, as mentioned in the OP.
>
> I think this is roughly the same situation as was true with Rust:  https://reviews.llvm.org/D99981#2837256 - but I think in that case and in this one, it'd be good to break it down to better validate the code against LLVM's coding conventions and other code review scrutiny.

Not sure I'd say it's mandatory - other folks might have other opinions/perspectives/framing, but I tend to think it's the right way to go. (@jhenderson @rnk)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110576/new/

https://reviews.llvm.org/D110576