View mode: basic / threaded / horizontal-split · Log in · Help
June 11, 2009
[Issue 3065] New: error: this for variable needs to be Type not Type!(arguments).Type
http://d.puremagic.com/issues/show_bug.cgi?id=3065

          Summary: error: this for variable needs to be Type not
                   Type!(arguments).Type
          Product: D
          Version: 1.045
         Platform: Other
       OS/Version: Linux
           Status: NEW
         Keywords: diagnostic
         Severity: normal
         Priority: P2
        Component: DMD
       AssignedTo: nobody@puremagic.com
       ReportedBy: dhasenan@gmail.com


This message is vague because it does not include any template parameters the
type may have. It is especially galling because the arguments are included in
the second part and not the first.

One fix is expression.c:270, check if ad->type is null. If it is, use the
current code. Otherwise, use ad->type->toChars rather that ad->toChars.

The other fix is to have AggregateDeclaration::toChars return type->toChars if
type is not null.

Since the latter is more general, I favor it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 11, 2009
[Issue 3065] error: this for variable needs to be Type not Type!(arguments).Type
http://d.puremagic.com/issues/show_bug.cgi?id=3065





--- Comment #1 from Chris Wright <dhasenan@gmail.com>  2009-06-11 16:35:33 PDT ---
Created an attachment (id=399)
--> (http://d.puremagic.com/issues/attachment.cgi?id=399)
implements the more general fix described

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 13, 2009
[Issue 3065] error: this for variable needs to be Type not Type!(arguments).Type
http://d.puremagic.com/issues/show_bug.cgi?id=3065





--- Comment #2 from Chris Wright <dhasenan@gmail.com>  2009-06-12 17:27:05 PDT ---
Additionally, the fix I've found for this error is to access fields as:
(cast(typeof(this)this).field
or
this.tupleof[INDEX]

rather than the more typical:
this.field

My initial guess is that semantic is not being run on the relevant
AggregateDeclaration.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 12, 2011
[Issue 3065] error: this for variable needs to be Type not Type!(arguments).Type
http://d.puremagic.com/issues/show_bug.cgi?id=3065


siegelords_abode@yahoo.com changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
                CC|                            |siegelords_abode@yahoo.com


--- Comment #3 from siegelords_abode@yahoo.com 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:

class A(T)
{
   this()
   {
       var = 5;
       cause_error;
   }

   int var;
}

void F(T)()
{
   auto a = new A!(T);
}

void main()
{
   F!(int)();
}

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: -------
Top | Discussion index | About this forum | D home