http://d.puremagic.com/issues/show_bug.cgi?id=4042

           Summary: Unable to instantiate a struct template.
           Product: D
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: e.insafutdinov@gmail.com


--- Comment #0 from Eldar Insafutdinov <e.insafutdinov@gmail.com> 2010-04-02 10:25:58 PDT ---
Created an attachment (id=598)
testcase

When compiling the attached code I get

main.d(51): Error: this for ref_ needs to be type QList not type
QList!(QGraphicsWidget)
main.d(51): Error: struct main.QList!(QGraphicsWidget).QList member ref_ is not
accessible

This bug caused a lot of headache and held off development of QtD for quite a while. I was finally able to reduce it to the sensible sized test-case(originally the number of source files was about 500). If you play with the testcase you'll find out that even slight modifications will lead to change of the error message or to disappearing of it. Something is going horribly wrong in the compiler. The version I tested it with is 2.042 which is not present on the list.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4042


Max Samukha <samukha@voliacable.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |samukha@voliacable.com


--- Comment #1 from Max Samukha <samukha@voliacable.com> 2010-04-03 05:01:52 PDT ---
A corrected and smaller test-case:

template isQObjectType(T)
{
    enum isQObjectType = is(T.__isQObjectType);
}

template QTypeInfo(T)
{
    static if (!isQObjectType!T)
    {
        enum size = T.sizeof;
    }
}

struct QList(T)
{
    alias QTypeInfo!T TI;
    int x;

    void foo()
    {
        x++;
    }
}

void exec(QList!(QAction) actions) {}

interface IQGraphicsItem
{
}

abstract class QGraphicsObject : IQGraphicsItem
{
}

class QGraphicsWidget : QGraphicsObject
{
}

class QAction
{
    final void associatedGraphicsWidgets(QList!(QGraphicsWidget) a)
    {
        QList!(QGraphicsWidget) x;
    }
}

void main()
{
}
----

There may be more than one bug. Note that the static if body in QTypeInfo is evaluated even though no __isQObjectType is defined in QGraphicsWidget or QAction.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4042



--- Comment #2 from Max Samukha <samukha@voliacable.com> 2010-04-03 05:25:22 PDT ---
> There may be more than one bug. Note that the static if body in QTypeInfo is evaluated even though no __isQObjectType is defined in QGraphicsWidget or QAction.

Ignore that part. It's the other way around. If we add, for example, "alias void __isQObjectType;" to QGraohicsWidget/QAction, the "static if" condition is satisfied in QTypeInfo, though it should not.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

The test case compiles when exec method definition is moved down:
template isQObjectType(T)
{
    enum isQObjectType = is(T.__isQObjectType);
}

template QTypeInfo(T)
{
    static if (!isQObjectType!T)
    {
        enum size = T.sizeof;
    }
}

struct QList(T)
{
    alias QTypeInfo!T TI;
    int x;

    void foo()
    {
        x++;
    }
}


interface IQGraphicsItem
{
}
void exec(QList!(QAction) actions) {}

abstract class QGraphicsObject : IQGraphicsItem
{
}

class QGraphicsWidget : QGraphicsObject
{
}

class QAction
{
    final void associatedGraphicsWidgets(QList!(QGraphicsWidget) a)
    {
        QList!(QGraphicsWidget) x;
    }
}

void main()
{
}

http://d.puremagic.com/issues/show_bug.cgi?id=4042


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2010-05-09 17:56:02 PDT ---
Thanks for the reduced test case.

This is a rather nasty problem. The essence of it is that when the is(T.__isQObjectType) is evaluated, T is forward referenced. So it attempts to forward instantiate T. This fails, and so the IsExpression fails.

The problem is that in the attempt to forward instantiate T, it doesn't quite reset itself back to the state it was in before the IsExpression, and now parts of the symbol table are in an "error" state, and a cascaded error message (hence incomprehensible) comes out as a result.

A workaround is to remove 'abstract' from the class declaration, which enables the forward instantiation to succeed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4042



--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> 2010-05-09 19:53:56 PDT ---
Trying to perfectly unwind forward reference failures is buggy and probably doomed. This one fails because function parameter types don't get redone. While it's easy to fix that one, there are just more lurking. A better approach is to make forward references always work, something I've been working towards for a while.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4042



--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> 2010-05-09 20:00:03 PDT ---
changelog 477

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4042



--- Comment #6 from Eldar Insafutdinov <e.insafutdinov@gmail.com> 2010-05-10 03:31:35 PDT ---
(In reply to comment #5)
> changelog 477

Thanks for that. I will check if it fixes our problem later today. And I am also looking forward to properly fix of forward references. This particular bug may be fixed, but who knows if other will appear. It still persists as a serious problem to me. Eliminating forward references completely will increase the quality of the compiler significantly.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4042



--- Comment #7 from Max Samukha <samukha@voliacable.com> 2010-05-10 07:45:38 PDT ---
*** Issue 4043 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4042



--- Comment #8 from Max Samukha <samukha@voliacable.com> 2010-05-10 08:01:05 PDT ---
(In reply to comment #5)
> changelog 477

Qtd compiles with that. Thank you.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------