For the lulz: ddmd vs libdparse lexer timings

[Daniel Murphy via Digitalmars-d]

"Iain Buclaw via Digitalmars-d"  wrote in message 
news:mailman.4143.1420452193.9932.digitalmars-d at puremagic.com...

> That depends on how we agree to go forward with this.  From memory, we
> each do / did things differently.
>
> I have no doubt that the way I've done it is a kludge at best, but
> I'll explain it anyway.
>
> GDC *always* uses the real va_list type, our type-strict backend
> demands at least that from us.  So when it comes down to the problem
> of passing around va_list when it's a static array (extern C expects a
> ref), I rely on people using core.vararg/gcc.builtins to get the
> proper __builtin_va_list before importing modules such as
> core.stdc.stdio (printf and friends) - as these declarations are then
> rewritten by the compiler from:
>
> int vprintf(__builtin_va_list[1] va, in char* fmt, ...)
>
> to:
>
> int vprintf(ref __builtin_va_list[1] va, in char* fmt, ...)
>
>
> This is an *esper* workaround, and ideally, I shouldn't be doing this...

I just read the discussion in 
https://github.com/D-Programming-Language/dmd/pull/3568 and I think I 
finally get it, lol.

AIUI your solution won't work for user C++ functions that take va_list, 
because either type or mangling will be correct, but never both.  Is that 
correct?  Can gdc compile the tests in 3568?

I'm going to have a look at turning va_list into a magic type that the 
compiler will pass by reference when necessary and always mangle correctly.