Comment #0 by bus_dbugzilla — 2011-11-17T18:20:08Z
class A()
{
alias C!() C1;
}
class B
{
alias A!() A1;
}
class C() : B
{
}
>dmd -c text.d
test.d(9): Error: class test.C!().C has forward references
test.d(7): Error: template instance test.A!() error instantiating
Problem cannot be worked around by rearranging order of declaration. All 6 possible orders exhibit the "has forward references" error.
Might be related to #3834
Comment #1 by bus_dbugzilla — 2011-11-21T13:50:16Z
Severity -> critical
This is blocking a major refactoring in my project.
Comment #2 by bus_dbugzilla — 2011-12-06T16:57:34Z
I'm not very familiar with DMD's internals wrt semantics, but from what I can tell so far, the problem may have to do with a certain section near the end of TemplateInstance::semantic(Scope *sc, Expressions *fargs):
...
/* The problem is when to parse the initializer for a variable.
* Perhaps VarDeclaration::semantic() should do it like it does
* for initializers inside a function.
*/
// if (sc->parent->isFuncDeclaration())
/* BUG 782: this has problems if the classes this depends on
* are forward referenced. Find a way to defer semantic()
* on this template.
*/
semantic2(sc2);
...
That call to semantic2 is the call stack when the "has forward references" error is thrown. Note that this occurs before tryMain() reaches semantic2.
Do to my inexperience with DMD's internals, I have no idea if there's some reason that call to semantic2 is supposed to be there. And I don't understand what those comments are trying to say. But if I comment out that semantic2 call, the test case passes. However, I don't know whether that breaks anything else.
Comment #3 by bus_dbugzilla — 2011-12-06T16:59:05Z
*Ahem*:
"That call to semantic2 is *IN* the call stack..."
Comment #4 by bus_dbugzilla — 2012-04-23T17:58:53Z
Commenting out that call to semantic2 no longer fixes the problem in latest DMD in Git (and Phobos fails to rebuild with the change). So I've got no clue. But this is still blocking me from some major refactoring I need to do.
Comment #5 by bugzilla — 2012-04-28T02:04:29Z
It's not really a forward reference, it's a circular one. B is defined in terms of itself. I'm not sure how this could ever work.
Comment #6 by bus_dbugzilla — 2012-04-29T21:23:36Z
This works:
class A
{
alias C C1;
}
class B
{
alias A A1;
}
class C : B
{
}
Comment #7 by alanb — 2012-11-10T00:39:04Z
(In reply to comment #6)
> This works:
>
> class A
> {
> alias C C1;
> }
> class B
> {
> alias A A1;
> }
> class C : B
> {
> }
It works because there are no actual circular references, and that's because the class alias are in reality pointers, and pointers are known data types irrespective of what they may represent (the definition expansion should stop at the pointer). The compiler is certainly able to determine what the pointers represent for dereferencing purposes as the class structures and contents are 100% knowable.
Note that if you convert the pointers to represent structs, ie change class to struct, and fix up struct C to contain struct B due to a lack of inheritance, it will no longer work, which is to be expected. To make the struct version work again, you simply change the contained B to a pointer.
// this fails, and it should fail, so we're good.
struct A()
{
C!() C1;
}
struct B
{
A!() A1;
}
struct C()
{
B s;
}
// this works, and it should work, so we're good.
struct A()
{
C!() C1;
}
struct B
{
A!() A1;
}
struct C()
{
B* s; // changed to pointer
}
The problem at hand is definitely a bug from what I see.
--rt
Comment #8 by alanb — 2012-11-10T01:34:57Z
(In reply to comment #7)
> (In reply to comment #6)
I get weird behavior if I put in only the alias definitions.
This stuct version compiles, and it probably should because sA and sB are empty with no circular referencing.
struct sA()
{
alias sC!() sC1;
}
struct sB
{
alias sA!() sA1;
}
struct sC()
{
sB s;
}
But adding sA1 into sB will not compile, but I think it should compile because sA is empty and there's no circular reference back to sC.
struct sA()
{
alias sC!() sC1;
}
struct sB
{
alias sA!() sA1;
sA1 a;
}
struct sC()
{
sB b;
}
In fact it does compile in the non-template version as expected.
struct sA
{
alias sC sC1;
}
struct sB
{
alias sA sA1;
sA1 a;
}
struct sC()
{
sB b;
}
Finally, closing the loop will not compile as expected
struct sA
{
alias sC sC1;
sC1 c; // bang, we're dead.
}
struct sB
{
alias sA sA1;
sA1 a;
}
struct sC()
{
sB b;
}
Templates and non-templates are being evaluated inconsistently, so there's definitely a bug in there somewhere.