--- ~/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.
So this happens when compiling the linux and the posix header together? I think it's a problem with the circular import, will fix.
(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.
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
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.
https://github.com/D-Programming-Language/druntime/pull/644
Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/54ca71b154fd9476520a63e30a50980af8927a56 fix Issue 11301 - [2.064 beta] core.sys.linux.sys.mman triggers enum resolution error https://github.com/D-Programming-Language/druntime/commit/9c0a711cc48f0893e8c0790fc6b967fc5c637179 Merge pull request #644 from WalterBright/fix11301 fix Issue 11301 - [2.064 beta] core.sys.linux.sys.mman triggers enum res...
Commit pushed to 2.064 at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/2abb4b0e1c73bcf0ec7347c27ea945f90252c337 Merge pull request #644 from WalterBright/fix11301 fix Issue 11301 - [2.064 beta] core.sys.linux.sys.mman triggers enum res...
(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?
> 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?
(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.