[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