https://issues.dlang.org/show_bug.cgi?id=16666
Iain Buclaw <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from Iain Buclaw <[email protected]> --- (In reply to kinke from comment #3) > Raising importance to critical, as we seem to have hit the same problem with > v2.100, dustmited to a trivial > > ``` > // crypto.d: > import types; > > > // types.d: > import crypto; > version (WORKING) > struct EVP_KEYEXCH; > else static if (true) > struct EVP_KEYEXCH; > ``` > > `dmd -o- types.d` fails with an 'undefined identifier EVP_KEYEXCH' error; > `-version=WORKING` makes it work, showing the difference of static-if vs. > version condition. Compiling the other module (`dmd -o- crypto.d`) works > fine. Just highlights the linear expansion of imports and static if's in a compilation. module crypto -> import object -> import types -> module types -> import object -> import crypto -> module crypto -> static if (true) -> struct EVP_KEYEXCH -> int EVP_PKEY_derive_init_ex(EVP_KEYEXCH*) vs. module types; -> import object -> import crypto -> module crypto -> import object -> import types -> module types -> int EVP_PKEY_derive_init_ex(EVP_KEYEXCH*) I can't see myself being happy with anything other than a total rethink of how the first semantic pass walks over all nodes. The "quick fix" would be to extend this related PR fix to look in more places. https://github.com/dlang/dmd/pull/9873 But that would open up a Pandora's box more problems. --
