Am Sun, 13 Jan 2013 22:54:12 +0000
schrieb Iain Buclaw <ibuc...@ubuntu.com>:
>
> multiobj is ignored by gdc, but just for consistency reasons, just go
> with false.
OK, thanks
>
>
> Also, do you find that templates must go after *all* functions have
> been processed, or is it fine if you just add them to
> toSymbol()->deferredNestedFuncs for the function they are associated
> with to be processed immediately afterwards.
That would be fine in theory, as far as I understand this issue. But we
also have to emit class/struct/interface template instances at that
point, not only function template instances, so adding them to
deferredNestedFuncs is not practical.
(They must be emitted from the associated function as they have to
get the scope of that function)
OK, the frontend is more intelligent than I first though. If a template
instance is directly inside a struct, class or interface, the instance
is not added to the module-level members, it's added to the
class/struct/interface members instead. This means in those cases the
emission order / scope is already correct. It also means that templates
nested in templates etc need no additional work.
So it's only template instances nested in functions which needs some
special handling and the simple approach I showed should be mostly
working.
Then there's this case:
struct S(T)
{
void abcd()
{
void getChar()() //goes to module members array
{
}
getChar();
}
}
S!int instance; //Goes to module members array
Although emitting S!int now also emits getChar with my changes (so
correct scope), there's an issue if getChar is first emitted from the
module level members array and then S!int (so wrong scope).
I think the solution is to only emit templates that have .parent ==
module. It's important that we still emit all templates, but I think
emitting class/interface/struct/function nested + those nested directly
in module should cover all templates?
I'll see if those changes pass the test suite and file a pull request
if it works as expected.
