Very strange, because to me it looks like it actually imports - it imports `core.sys.posix.config` which in turns publicly imports `core.stdc.config`, but it doesn't work unless I put
```
import core.sys.posix.config: c_long;
```
inside core.sys.posix.sys.types.
Comment #2 by duser — 2022-03-27T17:24:25Z
underlying issue seems to be this:
// main.d
my_long x;
import core_stdc_config;
// core_stdc_config.d
static if (1)
alias my_long = long;
else
alias my_long = long;
main.d(1): Error: undefined identifier `my_long`
error goes away if "my_long x;" is moved after the import, ": my_long" is added to make it a selective import, or if the "static if" is removed
Comment #3 by kinke — 2022-06-02T16:49:19Z
Raising importance to critical, as we seem to have hit the same problem with v2.100, dustmited to a trivial
```
// crypto.d:
import types;
int EVP_PKEY_derive_init_ex(EVP_KEYEXCH*);
// 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.
Comment #4 by ibuclaw — 2022-06-03T16:23:28Z
(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.
Comment #5 by robert.schadek — 2024-12-13T18:50:35Z