Bug 22926 – importC: cast to D type alias in array length gives syntax error

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

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];

I'm thinking of adding __cast: char cs[__cast(int32_t)1]; which will resolve the ambiguity.

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

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.

(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.

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.