Fix #141: Improve type inference for macros, in particular handle type arguments.

[ciechowoj]

The commit learns dstep to infer the signature of the macro basing on usage. It is still quite rudimentary implementation but it handles the cases that were wrong before anyway. Example:

assertTranslates(q"C
#define BAR(x, y, z) x * y * sizeof(z)

#define BAZ BAR(0, 1, float)
C", q"D
extern (C):

extern (D) auto BAR(z, T0, T1)(auto ref T0 x, auto ref T1 y)
{
    return x * y * z.sizeof;
}

enum BAZ = BAR!float(0, 1);
D");

More examples in unit tests.

[jacob-carlborg]

Is there a reason why constructors are not used?

[ciechowoj]

Yes, you cannot create (allocate on the heap) the associative array in the constructor.

[ciechowoj]

@jacob-carlborg What about making a little review : ) ?

[jacob-carlborg]

Yes, sorry. I've been busy with non-D related things.

[jacob-carlborg]

This is translated like this because at this point we don't know what BAR is?

[ciechowoj]

Yes, do you think BAR!int() is better?

[jacob-carlborg]

Well, BAR(int); doesn't compile, regardless if BAR is defined in the D code or not. So yes I think BAR!int() is better.

[ciechowoj]

It turns out that it isn't that trivial to change it (more than 1h of work), can we merge it as is for now? I don't have time to fix it right now. Maybe I'll manage after winter...

[jacob-carlborg]

Sure, can you rebase please.

[ciechowoj]

Do you remember what you meant by rebase? There is no merge conflict after all.

[jacob-carlborg]

No. The only thing I can think of is perhaps it's behind master.

[ciechowoj]

Rebased.

[jacob-carlborg]

Thanks.