I'm currently testing the semantic analysis of Descent, to match it with DMD's. I'm trying to get zero errors on phobos. There's one thing I don't understand. In module internal.gc.gc there's this line:

public import gcx;

At the root of phobos there is no file named gcx.d, but in internal/gc/ there is one. That file doesn't have a module declaration (no "module ...;"). So I thought "Oh, since it doesn't have a module declaration, the module's name is gcx (the filename minus .d), and that's why the public import works". But... When compiling this piece of code:

---
import internal.gc.gc;
---

I get:
..\dmd\bin\..\src\phobos\internal\gc\gc.d(37): module gcx cannot read file 'gcx.d'

So... is there an error in internal.gc.gc? If so... how does phobos gets compiled? Should I ignore that kind of errors while testing Descent on phobos?

"Ary Borenszweig" <ary@esperanto.org.ar> wrote in message news:fmbqi6$o01$1@digitalmars.com...
> I'm currently testing the semantic analysis of Descent, to match it with DMD's. I'm trying to get zero errors on phobos. There's one thing I don't understand. In module internal.gc.gc there's this line:
>
> public import gcx;
>
> At the root of phobos there is no file named gcx.d, but in internal/gc/ there is one. That file doesn't have a module declaration (no "module ...;"). So I thought "Oh, since it doesn't have a module declaration, the module's name is gcx (the filename minus .d), and that's why the public import works". But... When compiling this piece of code:
>
> ---
> import internal.gc.gc;
> ---
>
> I get:
> ..\dmd\bin\..\src\phobos\internal\gc\gc.d(37): module gcx cannot read file
> 'gcx.d'
>
> So... is there an error in internal.gc.gc? If so... how does phobos gets compiled? Should I ignore that kind of errors while testing Descent on phobos?

The GC is compiled as a single piece of the library.  If you were to compile gc.d from the /internal/gc directory, you would import gcx.d by using "import gcx;", which is exactly what's going on here.

The downside is that if you're _not_ compiling from /internal/gc, you can't import internal.gc.gcx, since now it's nested in a directory, so the FQN now becomes "internal.gc.gcx".

So either skip that dir when testing Descent, or set your path to it when testing it so that gcx comes into the "root" namespace.

Thanks Jarrett.

Jarrett Billingsley escribió:
> "Ary Borenszweig" <ary@esperanto.org.ar> wrote in message news:fmbqi6$o01$1@digitalmars.com...
>> I'm currently testing the semantic analysis of Descent, to match it with DMD's. I'm trying to get zero errors on phobos. There's one thing I don't understand. In module internal.gc.gc there's this line:
>>
>> public import gcx;
>>
>> At the root of phobos there is no file named gcx.d, but in internal/gc/ there is one. That file doesn't have a module declaration (no "module ...;"). So I thought "Oh, since it doesn't have a module declaration, the module's name is gcx (the filename minus .d), and that's why the public import works". But... When compiling this piece of code:
>>
>> ---
>> import internal.gc.gc;
>> ---
>>
>> I get:
>> ..\dmd\bin\..\src\phobos\internal\gc\gc.d(37): module gcx cannot read file 'gcx.d'
>>
>> So... is there an error in internal.gc.gc? If so... how does phobos gets compiled? Should I ignore that kind of errors while testing Descent on phobos?
> 
> The GC is compiled as a single piece of the library.  If you were to compile gc.d from the /internal/gc directory, you would import gcx.d by using "import gcx;", which is exactly what's going on here.
> 
> The downside is that if you're _not_ compiling from /internal/gc, you can't import internal.gc.gcx, since now it's nested in a directory, so the FQN now becomes "internal.gc.gcx".
> 
> So either skip that dir when testing Descent, or set your path to it when testing it so that gcx comes into the "root" namespace. 
> 
>