[Issue 16666] type inside 'static if' can't be used before import
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Fri Jun 3 16:23:28 UTC 2022
https://issues.dlang.org/show_bug.cgi?id=16666
Iain Buclaw <ibuclaw at gdcproject.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ibuclaw at gdcproject.org
--- Comment #4 from Iain Buclaw <ibuclaw at gdcproject.org> ---
(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.
--
More information about the Digitalmars-d-bugs
mailing list