On Sep 1, 2010, at 12:58 PM, Don Clugston wrote:

> On 1 September 2010 21:35, Sean Kelly <sean at invisibleduck.org> wrote:
>> This one is really more of a programming question, but it's mangling related so I figured I'd ask here anyway.  The following function:
>> 
>>    void someFunc(real x)() {}
>>    someFunc!(1234.5678);
>> 
>> is mangled as:
>> 
>>    D8demangle34__T8someFuncVde9A522B6AE7D566CFP7Z8someFuncFZv
>> 
>> std.demangle assumes that when it encounters an 'e' in a template parameter list, the next 20 bytes will be a hex representation of an 80 bit floating point value.  The ABI and current mangling behavior is to represent things a bit differently with a variable width hex mantissa and exponent value (HexDigits P Number).  So in this case I have 8 bytes of mantissa (9A 52 2B 6A E7 D5 66 CF) and 1 byte of exponent (7).  I'm having trouble relating the mangled value to 1234.5678 though.  Can someone explain what's going on here, and possibly suggest an appropriate means for converting the mangled value to a textual representation?
> 
> The mangled value is just the %A representation of the number.
> ulong u = 0x9A522B6AE7D566CFL;
> writefln("%A  %X", 1234.5678L, (u<<1));
> ---prints---
> 0X1.34A456D5CFAACD9EP+10  34A456D5CFAACD9E
> Note that the exponent is decimal, not hex.

Why the left shift to get the original %A representation?  From the code Walter attached, I wouldn't expect that step.

On Sep 1, 2010, at 3:29 PM, Sean Kelly wrote:

> On Sep 1, 2010, at 12:58 PM, Don Clugston wrote:
>> 
>> The mangled value is just the %A representation of the number.
>> ulong u = 0x9A522B6AE7D566CFL;
>> writefln("%A  %X", 1234.5678L, (u<<1));
>> ---prints---
>> 0X1.34A456D5CFAACD9EP+10  34A456D5CFAACD9E
>> Note that the exponent is decimal, not hex.
> 
> Why the left shift to get the original %A representation?  From the code Walter attached, I wouldn't expect that step.

Forget I said anything.  The %LA output of 1234.5678 is "0X9.A522B6AE7D566CFP+7"  I should have checked this first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20100901/0e9a9457/attachment.html>

On Aug 31, 2010, at 12:06 AM, Don Clugston wrote:

> On 31 August 2010 05:58, Sean Kelly <sean at invisibleduck.org> wrote:
>> One other thing.  The ABI has "i Number" under "Value" for templates, but demangle() doesn't handle this and the ABI is totally silent on what it is.  Any idea?  I suppose I could just check the DMD source though.
> 
> Svn 370. Which I think was a really bad idea. The i should always be there, for any positive number. It's a fantasy to think that the ABI is stable at this point (eg, bug 3398 "Attributes inside a union screws data alignment" has only just been fixed). We could fix all remaining ABI issues in one go, then declare it stable.

I just ran into this one, and it's an annoyance more than anything else.  The function:

    fn!([1:2, 3:4])();

is mangled as:

    _D8demangle21__T2fnVHiiA2i1i2i3i4Z2fnFZv

The pertinent part being the way associative arrays are mangled:

    HiiA2i1i2i3i4

The type is "Hii", so an AA of int->int.  Perfect.  But then the value is "A2i1i2i3i4", which taken by itself suggests an array literal, not an AA literal.  This is the only instance that I've encountered where the determined type has to be communicated to the value parser so it can demangle things correctly (since it would be otherwise treated as a plain old array literal and represented as "[1,2]").  It would be better if the representation for this AA were:

    HiiH2i1i2i3i4

Thoughts?

On May 20, 2011, at 3:02 PM, Sean Kelly wrote:
> 
> I just ran into this one, and it's an annoyance more than anything else.

Here's another one.  An inout(T) function parameter is represented as "NgT" (ie. Wild T, per the ABI).  'N' is already used as the signifier for a FuncAttr, so this function:

    nothrow inout(int) fn(inout(int) x) { return x; }

Is mangled as:

    2fnFNbNgiZNgi

Parsing this, I have to explicitly recognize "Ng" as not a FuncAttr but rather the beginning of an inout parameter type, rewind the parse location (admittedly by one char) and jump out of the FuncAttr parse loop to deal with it.  Couldn't some other label be used to mark an inout parameter so this conflict doesn't exist?  I guess TypeNewArray might have this same problem ("Ne") except that it isn't even used in D2 right now so I suppose that's a non-issue.

Please submit these to bugzilla, else they'll get lost in this ancient thread!

On 5/20/2011 3:59 PM, Sean Kelly wrote:
> On May 20, 2011, at 3:02 PM, Sean Kelly wrote:
>> I just ran into this one, and it's an annoyance more than anything else.
> Here's another one.  An inout(T) function parameter is represented as "NgT" (ie. Wild T, per the ABI).  'N' is already used as the signifier for a FuncAttr, so this function:
>
>      nothrow inout(int) fn(inout(int) x) { return x; }
>
> Is mangled as:
>
>      2fnFNbNgiZNgi
>
> Parsing this, I have to explicitly recognize "Ng" as not a FuncAttr but rather the beginning of an inout parameter type, rewind the parse location (admittedly by one char) and jump out of the FuncAttr parse loop to deal with it.  Couldn't some other label be used to mark an inout parameter so this conflict doesn't exist?  I guess TypeNewArray might have this same problem ("Ne") except that it isn't even used in D2 right now so I suppose that's a non-issue.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>

Done.  The issue numbers are: 3034, 6525, 6526, 6527.

On May 20, 2011, at 4:24 PM, Walter Bright wrote:

> Please submit these to bugzilla, else they'll get lost in this ancient thread!
> 
> On 5/20/2011 3:59 PM, Sean Kelly wrote:
>> On May 20, 2011, at 3:02 PM, Sean Kelly wrote:
>>> I just ran into this one, and it's an annoyance more than anything else.
>> Here's another one.  An inout(T) function parameter is represented as "NgT" (ie. Wild T, per the ABI).  'N' is already used as the signifier for a FuncAttr, so this function:
>> 
>>     nothrow inout(int) fn(inout(int) x) { return x; }
>> 
>> Is mangled as:
>> 
>>     2fnFNbNgiZNgi
>> 
>> Parsing this, I have to explicitly recognize "Ng" as not a FuncAttr but rather the beginning of an inout parameter type, rewind the parse location (admittedly by one char) and jump out of the FuncAttr parse loop to deal with it.  Couldn't some other label be used to mark an inout parameter so this conflict doesn't exist?  I guess TypeNewArray might have this same problem ("Ne") except that it isn't even used in D2 right now so I suppose that's a non-issue.
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> 
>> 
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Here's one I ran across working on formatting integer literal template parameters.  This declaration:

void fnA(alias x)() {}
alias fnA!([true:'a',false:'b']) fn;

Is mangled as:

_D8demangle24__T3fnAVHbaA2i1i97i0i98Z3fnAFZv

So the template parameter type is "Hba", the list of values is "A2?" and the values themselves are all represented as integers, ie. "i1" for "true", "i97" for "a", etc.  I'm inclined to say that the mangling should reflect the actual type of the values rather than using 'i' as a catch-all.  Does anyone disagree?  Combined with the fix for AA literals, I think the encoding should be:

_D8demangle24__T3fnAVHba2b1a97b0a98Z3fnAFZv

On Aug 31, 2011, at 4:18 PM, Sean Kelly wrote:

> Here's one I ran across working on formatting integer literal template parameters.  This declaration:
> 
> void fnA(alias x)() {}
> alias fnA!([true:'a',false:'b']) fn;
> 
> Is mangled as:
> 
> _D8demangle24__T3fnAVHbaA2i1i97i0i98Z3fnAFZv
> 
> So the template parameter type is "Hba", the list of values is "A2?" and the values themselves are all represented as integers, ie. "i1" for "true", "i97" for "a", etc.  I'm inclined to say that the mangling should reflect the actual type of the values rather than using 'i' as a catch-all.  Does anyone disagree?  Combined with the fix for AA literals, I think the encoding should be:
> 
> _D8demangle24__T3fnAVHba2b1a97b0a98Z3fnAFZv


I think I missed an 'H' in there:

_D8demangle24__T3fnAVHbaH2b1a97b0a98Z3fnAFZv

On 8/31/2011 4:18 PM, Sean Kelly wrote:
> Here's one I ran across working on formatting integer literal template parameters.  This declaration:
>
> void fnA(alias x)() {}
> alias fnA!([true:'a',false:'b']) fn;
>
> Is mangled as:
>
> _D8demangle24__T3fnAVHbaA2i1i97i0i98Z3fnAFZv
>
> So the template parameter type is "Hba", the list of values is "A2?" and the values themselves are all represented as integers, ie. "i1" for "true", "i97" for "a", etc.  I'm inclined to say that the mangling should reflect the actual type of the values rather than using 'i' as a catch-all.  Does anyone disagree?  Combined with the fix for AA literals, I think the encoding should be:
>
> _D8demangle24__T3fnAVHba2b1a97b0a98Z3fnAFZv
>

As long as its decipherable, I don't see a point. Also, the mangling should be as short as practical. Spelling out 'true' is a waste.

The current scheme just complicates demangling if the bool should be displayed as true/false instead of 1/0. I'd have to pull the actual element type out of the Hba and pass it in as an alternate type when parsing the integer value. Since the mangled name is the same length either way, it seemed like it might be a worthwhile convenience.

Sent from my iPhone

On Aug 31, 2011, at 5:33 PM, Walter Bright <walter at digitalmars.com> wrote:

> 
> 
> On 8/31/2011 4:18 PM, Sean Kelly wrote:
>> Here's one I ran across working on formatting integer literal template parameters.  This declaration:
>> 
>> void fnA(alias x)() {}
>> alias fnA!([true:'a',false:'b']) fn;
>> 
>> Is mangled as:
>> 
>> _D8demangle24__T3fnAVHbaA2i1i97i0i98Z3fnAFZv
>> 
>> So the template parameter type is "Hba", the list of values is "A2?" and the values themselves are all represented as integers, ie. "i1" for "true", "i97" for "a", etc.  I'm inclined to say that the mangling should reflect the actual type of the values rather than using 'i' as a catch-all.  Does anyone disagree?  Combined with the fix for AA literals, I think the encoding should be:
>> 
>> _D8demangle24__T3fnAVHba2b1a97b0a98Z3fnAFZv
>> 
> 
> As long as its decipherable, I don't see a point. Also, the mangling should be as short as practical. Spelling out 'true' is a waste.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals