This bug may have already been reported, but as far as know it's a new one.

I got it down to 3 small files. (I started out with many, many files.) It looks like a nitpick in it's present form, but it's not. (At least, not when you're trying to work with thousands of lines of code.)

Here's the cryptic error message:
windows.d: module windows winnt.memset is private

In some manifestations of the error (8 files are involved instead of 3), a line number is included, but filename is mismatched with the line number:
..\win32\windef.d(3): module windef winnt.memset is private

This is very confusing because the third line of windef.d is that instance was a comment.

So here's the 3 file set:



I compiled them like this...
dmd direct.d windows.d winnt.d windef.d -c



/* *** direct.d *** */

module direct;

private	import windows;
extern(Windows)
{
  struct DDSURFACEDESC {}
  interface IDirectDrawSurface {}
}

class DirectApp
{
  IDirectDrawSurface createOffscreen()
  {
    DDSURFACEDESC desc;
		
/* The following line should be mentioned in the error message. */
    memset( &desc, 0, DDSURFACEDESC.size );
    return null;
  }
}



/* *** windows.d *** */
module windows;
import winnt;



/* *** winnt.d *** */
module winnt;

/* The following line should be mentioned in the error message. */
private extern(C) { void* memset(void*, uint, uint); }

  /* changing private to public removes the error,
  but hindsight is always 20/20 */



-- 
Justin
http://jcc_7.tripod.com/d/

J C Calvarese wrote:

> This bug may have already been reported, but as far as know it's a new one.
> 
> I got it down to 3 small files. (I started out with many, many files.) It looks like a nitpick in it's present form, but it's not. (At least, not when you're trying to work with thousands of lines of code.)
> 
> Here's the cryptic error message:
> windows.d: module windows winnt.memset is private
> 
> In some manifestations of the error (8 files are involved instead of 3),
> a line number is included, but filename is mismatched with the line number:
> ..\win32\windef.d(3): module windef winnt.memset is private

I got the 8 files down to 4.

Here's my compile line:
dmd direct.d windows.d winnt.d

(I would've put windef.d in the compile line, but that message is too boring.)

Here's the error message:
windef.d(4): module windef winnt.memset is private

The line number (4) seems to refer to a line in windows.d.
The file specified (windef) actually imports the questionable code on
line 3. The questionable code is actually on line 9 of winnt.d. The
other part of the problem is line 34 of direct.d (which would be nice to
know also).

-- 
Justin
http://jcc_7.tripod.com/d/

J C Calvarese wrote:

| module windef;
| import winnt;

| module winnt;
| import windef;

Is that a circular import?

SO long.

Manfred Nowak wrote:
> J C Calvarese wrote:
> 
> | module windef;
> | import winnt;
> 
> | module winnt;
> | import windef;
> 
> Is that a circular import?
Good point. I didn't mean to make it a circular import. The error occurs even if it's not a circular import. (And I'm pretty sure if they're done "properly", circular imports are allowed in D.)

Thanks for your input.

> 
> SO long.

I still get this error message:
windef.d(4): module windef winnt.memset is private

Here's the example without the circular import:

(Compile like this... dmd direct.d windows.d winnt.d)


-- 
Justin
http://jcc_7.tripod.com/d/

J C Calvarese wrote:

> Here's the example without the circular import:
> (Compile like this... dmd direct.d windows.d winnt.d)

Confirmed. But i can not figure out in the source of dmd where this message ist generated.

Including windef.d into the list of modules to be compiled make the line number disappear. So the compiler is "unsure" where the error really is.

So long.

Manfred Nowak wrote:

> J C Calvarese wrote:
> 
> 
>>Here's the example without the circular import:
>>(Compile like this... dmd direct.d windows.d winnt.d)
> 
> 
> Confirmed. But i can not figure out in the source of dmd where this
> message ist generated.
> 
> Including windef.d into the list of modules to be compiled make the line
> number disappear. So the compiler is "unsure" where the error really is.

I noticed this, too.

Part of the reason I posted the bug report was because the compiler seems to be acting erratically around this issue. I think that indicates a weakness in the compiler that Walter might want to improve. It might be at the bottom of his TO-DO list, but I think it should be on the list.

Incidently, on the practical side, I found the error went away when I declared memset in the file that uses memset. If I had realized that's what the compiler had hinted for me to do in the beginning, I might have fixed this quite a while ago. Oh, well.

> 
> So long.


-- 
Justin
http://jcc_7.tripod.com/d/