https://issues.dlang.org/show_bug.cgi?id=22926

duser@neet.fi changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|importC: can't use offsetof |importC: cast to D type
                   |in array length             |alias in array length gives
                   |                            |syntax error

--- Comment #1 from duser@neet.fi ---
looked at this some more, the syntax error seems related to using a D type for the cast - size_t is implicitly imported from object.d in the example so it's not really a valid C program

the error in v2.099.0 was already fixed by https://github.com/dlang/dmd/pull/13736 but the cast with D types became a syntax error with https://github.com/dlang/dmd/pull/13831

here's a better example than the first one:

// test.c(2): Error: found `1` when expecting `]`
// test.c(2): Error: `=`, `;` or `,` expected to end declaration instead of `]`
__import core.stdc.stdint;
char cs[(int32_t)1];

--

https://issues.dlang.org/show_bug.cgi?id=22926

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> ---
I'm thinking of adding __cast:

    char cs[__cast(int32_t)1];

which will resolve the ambiguity.

--

https://issues.dlang.org/show_bug.cgi?id=22926

--- Comment #3 from duser@neet.fi ---
requiring a keyword to cast D types would affect the ability to use types defined in __builtins.di

there could be existing C code out there that does this:

  char cs[(__int32)1]; // with version (CRuntime_Microsoft)

this works with dmd v2.099.0 but fails with the syntax error on current dmd nightly

--

https://issues.dlang.org/show_bug.cgi?id=22926

--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> ---
The idea is that if the C code is using __import, then it has already diverged from using Standard C, so __cast is more palatible.

The fundamental issue here is the compiler cannot recognize cast expressions 100% when the type is an identifier, without knowing if that identifier is a typedef or not. Importing files that haven't been parsed yet means no typedef symbol table is available. Requiring the import files to be parsed first puts an ordering on the parsing that I'd really like to avoid.

--

https://issues.dlang.org/show_bug.cgi?id=22926

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--

https://issues.dlang.org/show_bug.cgi?id=22926

--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to duser from comment #0)
> struct S { int x, y; };
> char cs[ ((size_t)((char *)&((struct S *)0)->y - (char *)0)) ];
> 
> dmd v2.099.0:
>   Error: dereference of invalid pointer `cast(S*)0LU`
> current git master:
>   Error: identifier or `(` expected

This problem has been fixed.

--

https://issues.dlang.org/show_bug.cgi?id=22926

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=22938

--

https://issues.dlang.org/show_bug.cgi?id=22926

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Walter Bright <bugzilla@digitalmars.com> ---
Since the original problem is fixed, the import problem is a separate issue https://issues.dlang.org/show_bug.cgi?id=22938 and this one is closed.

--