> On 25/07/2022 14:13 CEST Jan Beulich <jbeul...@suse.com> wrote:
>
>
> On 25.07.2022 14:05, ibuc...@gdcproject.org wrote:
> >> On 25/07/2022 08:45 CEST Jan Beulich <jbeul...@suse.com> wrote:
> >> while commit 3f30a274913b ("libiberty: Update D symbol demangling
> >> for latest ABI spec") mentions in its description that tuple encoding
> >> has changed, there's no real adjustment to dlang_parse_tuple() there,
> >> nor are there any new (or replaced) test cases for that. Was this
> >> simply overlooked?
> >
> > Is there any specific example that fails to demangle, or are you just
> > skimming?
>
> I'm merely looking at the code alongside the ABI spec.
>
> > From what I recall, there is a couple places in the dlang_demangle parser
> > that handle ambiguities in a mangled symbol. The ABI change only added a
> > terminating 'Z', which makes said code that handles ambiguity redundant -
> > but of course kept around so we handle both old and new symbols.
>
> It's not just the addition of Z at the end but also the dropping of the
> number of elements at the beginning, aiui. It's actually that aspect
> which caught my attention, since the ABI doesn't talk about any number
> there, but the code fetches one.
>
Went to have a look at docarchives, but it appears to be down (that's on me, I
have been meaning to migrate the service to new servers).
Yes, your right, the number was indeed dropped too from the ABI.
https://web.archive.org/web/20170812061158/https://dlang.org/spec/abi.html#TypeTuple
TypeTuple:
B Number Parameters
https://dlang.org/spec/abi.html#TypeTuple
TypeTuple:
B Parameters Z
However, it gets worse the more I stare at it. Looks like it was not understood
what 'Number' meant in the old ABI. I assumed it was the encoded number of
tuple elements - same as static arrays - however what I see in the front-end is
instead an encoded buffer length.
https://github.com/gcc-mirror/gcc/blob/releases/gcc-10/gcc/d/dmd/dmangle.c#L312-L313
So the loop should instead be more like:
---
unsigned long len;
mangled = dlang_number (mangled, &len);
if (mangled == NULL)
return NULL;
string_append (decl, "Tuple!(");
const char *endp = mangled + len;
int elements = 0;
while (mangled != endp)
{
if (elements++)
string_append (decl, ", ");
mangled = dlang_type (decl, mangled, info);
if (mangled == NULL || mangled > endp)
return NULL;
}
string_append (decl, ")");
return mangled;
---
On top of that, TypeTuple is a compile-time-only type - it never leaks to the
code generator - so the grammar entry in the ABI is frivolous (although
internally, that it gets a mangle at all would save some memory as duplicated
types are merged).
Iain.
