|Posted by email@example.com|
in reply to firstname.lastname@example.org
Posted in reply to email@example.com
What |Removed |Added
--- Comment #3 from firstname.lastname@example.org 2011-02-12 10:32:13 PST ---
I've analyzed this error and I think I know why it happens. Here's a simple test case that reproduces the error:
var = 5;
auto a = new A!(T);
bug.d(5): Error: this for var needs to be type A not type bug.A!(int).A
bug.d(6): Error: undefined identifier cause_error
bug.d(14): Error: template instance bug.A!(int) error instantiating
instantiatied in bug.d(19): F!(int)
That cause_error is necessary, because the way this bug occurs is when the template fails to instantiate the first time, and then is instantiated again at a later point. Note that this bug occurs in my actual program without the unrelated error, I just couldn't get a better test case. This bug is similar to the bug 5046, although in my program you need to do what the above poster suggested: explicit this does NOT work.
Anyway, the reason this bug occurs is that when a template is instantiated the first time and it encounters an error, it aborts instantiation and the calling code tries to instantiate it later (this test case invokes this mechanism in expression.c:6293). Unfortunately, while instantiating the first time it registers the types in the string table. When the template is instantiated again, the template contents are syntax copied (in TemplateInstance::semantic()) and when analyzed, the newly copied types have different pointers than the ones in the string table, confusing the subsequent this resolution code.
Firstly, let me say that this deferred instantiation of a template looks like a giant hack, since from the code it looks like it's a memory leak.
Anyway, to fix it I tried the following things:
To determine whether this is of the same type or not I tried to compare it by ClassDeclaration::type instead of ClassDeclaration itself. This didn't work for some reason (although it did fix the test case, it broke my actual project).
I also tried to copy the string table at the beginning of TemplateInstance::semantic and restore it if the semantic pass failed, but that didn't work either (although it did fix the test case, it broke my actual project in a slightly different way).
Anyway... any other ideas of how to fix this?
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------