Comment #0 by e.insafutdinov — 2010-04-02T10:25:58Z
Created attachment 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.
Comment #1 by samukha — 2010-04-03T05:01:52Z
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.
Comment #2 by samukha — 2010-04-03T05:25:22Z
> 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.
Comment #3 by bugzilla — 2010-05-09T17:56:02Z
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.
Comment #4 by bugzilla — 2010-05-09T19:53:56Z
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.
Comment #5 by bugzilla — 2010-05-09T20:00:03Z
changelog 477
Comment #6 by e.insafutdinov — 2010-05-10T03:31:35Z
(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.
Comment #7 by samukha — 2010-05-10T07:45:38Z
*** Issue 4043 has been marked as a duplicate of this issue. ***
Comment #8 by samukha — 2010-05-10T08:01:05Z
(In reply to comment #5)
> changelog 477
Qtd compiles with that. Thank you.