I'm not sure if this has been posted before, but I've finally been able to put my finger on a bug that has been annoying me quite a few times, and still causes dmd to segfault. It occurs when imports are left out although they would be needed for inheritance.

A simple case for the problem is:

// A.d
module A;

private import B;

class A
{
}


// B.d
module B;

private import C;

class B : A
{
}


// C.d
module C;

private import A;
private import B;

void main() {}



The programming error is quite obvious: B.d should also import module A. The way it currently is, module A is only available via module C, which is a private import, which somehow makes the compiler crash.

What it should do is complain about class A being unknown in B.d.

I apologize if this is a known bug. I think private imports in general need to be reworked in dmd.

-Sebastian

>The programming error is quite obvious: B.d should also import module A. The way it currently is, module A is only available via module C, which is a private import, which somehow makes the compiler crash.
>
>What it should do is complain about class A being unknown in B.d.
>
>I apologize if this is a known bug. I think private imports in general need to be reworked in dmd.

I think this is independent of private/public imports. When I make all the
imports public it still seg-v's (on Linux) when trying "dmd -c C.d". Note that
the compiler has to load all imports public and private but that with private
imports it doesn't add the symbols to the global namespace.
Another factor might be the fact that the class names A and B clash with the
module names. I don't think modules and classes can share names, but I can't
remember exactly.

Ben Hinkle schrieb:
> I think this is independent of private/public imports. When I make all the
> imports public it still seg-v's (on Linux) when trying "dmd -c C.d". Note that
> the compiler has to load all imports public and private but that with private
> imports it doesn't add the symbols to the global namespace.
> Another factor might be the fact that the class names A and B clash with the
> module names. I don't think modules and classes can share names, but I can't
> remember exactly.
> 
> 
They can't? That'd be bad, because I do that all the time ^^

But it seems like that is the problem: When I change the class names to Ac and Bc, dmd correctly complains about it.

B.d(6): identifier 'Ac' is not defined
B.d(6): Ac is used as a type
B.d(6): class B.Bc base type must be class or interface, not void


Not sure if it's allowed to name a class the same as a module. Usually it works. I mean, what name should I call a module if not the name of the class defined in it? It's the same as I've always been doing in C++.

-Sebastian

Sebastian Beschke schrieb in news:ct0snt$16bg$1@digitaldaemon.com:
> Ben Hinkle schrieb:
> > I think this is independent of private/public imports. When I make all the
> > imports public it still seg-v's (on Linux) when trying "dmd -c C.d". Note that
> > the compiler has to load all imports public and private but that with private
> > imports it doesn't add the symbols to the global namespace.
> > Another factor might be the fact that the class names A and B clash with the
> > module names. I don't think modules and classes can share names, but I can't
> > remember exactly.
> >
> >
> They can't? That'd be bad, because I do that all the time ^^
>
> But it seems like that is the problem: When I change the class names to Ac and Bc, dmd correctly complains about it.
>
> B.d(6): identifier 'Ac' is not defined
> B.d(6): Ac is used as a type
> B.d(6): class B.Bc base type must be class or interface, not void

Modules and class identfiers are in 2 seperate namespaces.
The problem only occures if the 3 files are in one dir _and_ the compiler is run in the same dir.

Thomas