In DMD 1.049, this code used to work:
--
bug01a.d
----------
module bug01a;
import bug01b;
union any {}
typedef any ANY;
--
bug01b.d
-----------
module bug01b;
import bug01a;
struct circular_definition {
union {
ANY subany;
}
}
Later (not sure when, but have tested on DMD 1.059) - this code began failing with the message:
bug01a.d(4): Error: typedef bug01a.ANY circular definition
Now - this code fails and ICE's the compiler:
bug01a.d(4): Error: typedef bug01a.ANY circular definition
Segmentation fault
Other things to note about the bug, swapping the typedef and union declaration in bug01a.d works
--
bug02a.d
----------
module bug02a;
import bug02b;
typedef any ANY;
union any {}
However, adding another struct in the second module triggers it again
--
bug02b.d
----------
module bug02b;
import bug02a;
struct circular_definition {
union {
ANY subany;
}
}
struct triggers_bug {}
And ultimately, putting the import at the bottom means it compiles successfully all the time.
--
works01a.d
----------
module works01a;
typedef any ANY;
union any {}
import works01b;
Regards
Comment #1 by bearophile_hugs — 2010-08-01T05:15:08Z
According to Andrei 'typedef' will be removed from the language.
Is an 'alias' there giving the same troubles?
Comment #2 by ibuclaw — 2010-08-01T05:33:11Z
(In reply to comment #1)
> According to Andrei 'typedef' will be removed from the language.
> Is an 'alias' there giving the same troubles?
That it does not. Also, I thought typedef was being removed only for D2?
This is sad news for me...
Comment #3 by bearophile_hugs — 2010-08-01T06:18:10Z
You are right, typedef will be removed from D1 only.
Comment #4 by bearophile_hugs — 2010-08-01T06:19:10Z
You are right, typedef will be removed from D2 only.
Comment #5 by clugdbug — 2010-08-24T23:55:47Z
Both of the unions in the test case can be replaced with structs without changing the behaviour.
The union inside circular_definition must be anonymous. If it is given a name,
compilation succeeds.
Also, if union any {} is changed into: alias int any; then it segfaults on 2.038.
So the fact that it started segfaulting on the union case is probably not important.
Comment #6 by clugdbug — 2010-08-25T12:42:01Z
Bug 3976 is probably a duplicate of this one.
Comment #7 by clugdbug — 2010-08-26T07:40:22Z
*** Issue 3976 has been marked as a duplicate of this issue. ***
Comment #8 by clugdbug — 2010-09-29T00:27:35Z
Caused by svn 318, which was fixing bug 282 "Bizarre circular import nested name invisibility issue". Regression bug 3682 was introduced at the same time.
Comment #9 by ibuclaw — 2011-03-01T08:35:31Z
Created attachment 926
Fix issue4543 segv
Bump.
Patch to prevent ICE from occurring, but doesn't stop the forward reference error.
Comment #10 by ibuclaw — 2011-03-01T10:50:34Z
And have no testsuite regressions on Linux as a result of the patch.
Comment #11 by ibuclaw — 2011-03-24T12:24:59Z
Created attachment 934
issue4543
Attached fix for this issue.
Formal testcase:
=== a4543.d ===
import b4543;
class bclass {};
typedef bclass Tclass;
struct bstruct {}
typedef bstruct Tstruct;
=== b4543.d ===
import a4543;
class A {
struct {
Tclass a;
Tstruct b;
}
union {
Tclass c;
Tstruct d;
}
}
struct B {
struct {
Tclass a;
Tstruct b;
}
union {
Tclass c;
Tstruct d;
}
}
Comment #12 by ibuclaw — 2011-03-24T12:41:02Z
>--- a/src/class.c
>+++ b/src/class.c
>@@ -870,14 +870,14 @@ Dsymbol *ClassDeclaration::search(Loc loc, Identifier *ident, int flags)
> Dsymbol *s;
> //printf("%s.ClassDeclaration::search('%s')\n", toChars(), ident->toChars());
>
>- if (scope)
>+ if (scope && !symtab)
> { Scope *sc = scope;
> sc->mustsemantic++;
> semantic(sc);
> sc->mustsemantic--;
> }
>
>- if (!members || !symtab || scope)
>+ if (!members || !symtab)
> {
> error("is forward referenced when looking for '%s'", ident->toChars());
> //*(char*)0=0;
Here (and in StructDeclaration), if (!symtab) looks to be a sure sign that the semantic pass hasn't been started yet. Also, if (!members), the semantic won't run anyway, so you are in trouble even if you do call the semantic in the search method.
Extending the condition instead to (scope && !symtab) is enough to fix/bypass the forward reference errors for StructDeclaration's while not hurting bug282 which depends on the semantic being called. As for ClassDeclaration's, something extra is needed (as you can see above), I'm not sure of the importance of (scope) *needing* to be NULL here, but removing the check doesn't seem to harm (at least) the testsuite.
Regards
dlang/dmd pull request #10890 "Remove obsolete test for issue 4543" was merged into master:
- e5411c1cbeee57c5875fb6a1d6eb9782d3836cc4 by Geod24:
Remove obsolete test for issue 4543
Typedef is long gone and the test was typedef-specific.
https://github.com/dlang/dmd/pull/10890