---
~/Build/Source/druntime/src (2.064=)$ ../../dmd/src/dmd core/sys/linux/sys/mman.d
core/sys/posix/sys/mman.d(193): Error: alias core.sys.posix.sys.mman.MAP_ANON cannot resolve
---
(DMD a913ce4, druntime c0978e9)
This regresses build systems that automatically pull in module dependencies for compilation and don't have a special case for druntime. The druntiem build itself doesn't break, as this is a header-only module.
Comment #1 by code — 2013-10-24T01:55:42Z
So this happens when compiling the linux and the posix header together?
I think it's a problem with the circular import, will fix.
Comment #2 by code — 2013-10-24T02:05:47Z
(In reply to comment #1)
> So this happens when compiling the linux and the posix header together?
At least it also happens when compiling core.sys.linux.sys.mman on its own.
Comment #3 by bugzilla — 2013-10-26T13:26:40Z
Reduced test case:
------ a.d --------
public import b;
static if (1) enum {
MAP_ANON = 1,
}
------ b.d --------
static import a;
alias MAP_ANON = a.MAP_ANON;
-------------------
dmd -c a.d
Comment #4 by bugzilla — 2013-10-26T18:49:21Z
This also happens with 2.063, so it is not a regression.
The trouble is the declaration of a.MAP_ANON is hidden inside a conditionally compiled block. Because the exp of "static if (exp)" cannot be evaluated in advance, the compiler cannot know yet that the declarations in the block exist.
Then, when doing semantic analysis on module a, it looks up a.MAP_ANON. It doesn't find MAP_ANON in a, but a.d imports b.d, and b declares a MAP_ANON!
The error is the alias essentially resolves to itself, which is an error.
I think the only solution is to fix the druntime code so it doesn't trigger what is essentially an unresolvable forward reference error.
(In reply to comment #4)
> Then, when doing semantic analysis on module a, it looks up a.MAP_ANON.
I don't follow here, why is there a lookup of MAP_ANON during semantic analysis of a?
Comment #9 by bugzilla — 2013-10-29T13:06:19Z
> I don't follow here, why is there a lookup of MAP_ANON during semantic analysis
> of a?
How else can it resolve a.MAP_ANON?
Comment #10 by code — 2013-10-29T16:51:10Z
(In reply to comment #9)
> > I don't follow here, why is there a lookup of MAP_ANON during semantic analysis
> > of a?
>
> How else can it resolve a.MAP_ANON?
Module a defines MAP_ANON itself, hidden in the static if block.
So I presume the forward reference happens because the imported module b is semantically analyzed before a is analyzed.