Crashes DMD 2.063, is an error with DMD from git head:
class C: C.D{static class D{}}
The code should compile.
Comment #1 by andrej.mitrovich — 2013-07-18T06:42:00Z
That's a borderline enhancement request. It might potentially break code too, e.g. this currently works:
-----
class D
{
}
class C : D
{
static class D
{
}
}
-----
With the enhancement this would have to become a conflict, although the workaround would be easy: one could use 'class C : .D' (dot expression) for the global class and 'class C : D' for the nested one. But I'm not fond of such lookup rules where something in an inner scope ends up conflicting with an expression in an outer scope.
Well I don't think I've ever tried to use either of these samples so I don't have a strong opinion either way.
Comment #2 by timon.gehr — 2013-07-18T10:53:27Z
(In reply to comment #1)
> That's a borderline enhancement request.
No, it is a bug report. C.D is a perfectly fine base class.
> It might potentially break code too,
> e.g. this currently works:
>
> -----
> class D
> {
> }
>
> class C : D
> {
> static class D
> {
> }
> }
> -----
>
> With the enhancement this would have to become a conflict,
I am not arguing for any enhancement that would change the meaning of the above code.
> although the
> workaround would be easy: one could use 'class C : .D' (dot expression) for the
> global class and 'class C : D' for the nested one. But I'm not fond of such
> lookup rules where something in an inner scope ends up conflicting with an
> expression in an outer scope.
> ...
I generally like shadowing, but it would indeed be utterly pointless to look up a classes' parents inside its own scope.
Comment #3 by andrej.mitrovich — 2013-07-18T13:14:30Z
(In reply to comment #2)
> I am not arguing for any enhancement that would change the meaning of the above
> code.
Ah, so you want this to work:
class C: C.D{static class D{}}
but this to fail:
class C: D{static class D{}}
And the following would stay as-is:
class D { } class C: D{static class D{}} // inherits global D
If that's so then this is reasonable.
Comment #4 by k.hara.pg — 2013-08-05T01:39:06Z
*** Issue 10759 has been marked as a duplicate of this issue. ***
Comment #7 by andrej.mitrovich — 2013-08-05T06:53:52Z
ICE fixed, but the bug report will remain open for the rejects-valid code.
Comment #8 by k.hara.pg — 2013-11-20T21:40:47Z
*** Issue 10887 has been marked as a duplicate of this issue. ***
Comment #9 by k.hara.pg — 2013-11-20T22:36:52Z
(In reply to comment #7)
> ICE fixed, but the bug report will remain open for the rejects-valid code.
The members of class X are unknown during the resolution of the class X hierarchy. In other words, it's a limitation that whole class hierarchy must be already known when class members being iterated.
This is necessary to test self type inside class member scope.
class B {
void foo() {}
}
class C(T) : T
{
/* if C!T inherits B, override B.foo */
static if (is(C : B))
override void foo() {}
}
alais CB = C!B;
To return 'true' at the static if condition, the fact "C!B inherits B" should be already known.
For that, compiler determines whole class hierarchy before each class members semantic.
And, it is the exact behavior that current dmd does.
---
By the current semantic strategy for classes, the OP code won't be compiled. So this is not a rejects-valid bug.
To accept the OP code, we should drastically improve semantic analysis mechanism.
Change the importance to 'enhancement'.
Comment #10 by dlang-bot — 2023-01-16T01:26:06Z
@ibuclaw created dlang/dmd pull request #14826 "dmd.aggregate: Define importAll override for AggregateDeclaration" fixing this issue:
- fix Issue 10616 - forward reference error with class C: C.D{static class D{}}
https://github.com/dlang/dmd/pull/14826
Comment #11 by robert.schadek — 2024-12-13T18:09:14Z