Bug 22598 – importC: Add support for __extension__ keyword

In common system headers, the __extension__ keyword can crop up, i.e in assert.h, assert() is defined as: --- # define assert(expr) \ ((void) sizeof ((expr) ? 1 : 0), __extension__ ({ \ if (expr) \ ; /* empty */ \ else \ __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION); \ })) --- Here the __extension__ disables any ISO C warnings caused by the non-standards conforming syntax ({ ... }). By not allowing the same to be compilable by ImportC would prevent any code that uses assert.h from working.

I've worked around this by adding `#define __STRICT_ANSI__` to the sanitizer I run with the preprocessor.

The __extension__ documentation is confusing: "You can prevent such warnings within one expression by writing `__extension__' before the expression. `__extension__' has no effect aside from this." Yet in your example, __extension__({ if (expr); else ...}) is a statement, not an expression.

(In reply to Walter Bright from comment #2) > The __extension__ documentation is confusing: > > "You can prevent such warnings within one expression by > writing `__extension__' before the expression. `__extension__' has no > effect aside from this." > > Yet in your example, > > __extension__({ if (expr); else ...}) > > is a statement, not an expression. It’s a gnu statement expression. See https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html. It’s also supported by clang.

(In reply to dave287091 from comment #3) > It’s a gnu statement expression. See > https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html. It’s also supported > by clang. Too bad there's no grammar for it.

Once the `__extension__({ ... })` is parsed, what should the compiler do with it?

(In reply to Walter Bright from comment #5) > Once the `__extension__({ ... })` is parsed, what should the compiler do > with it? There’s two things going on in that example: the __extension__ just suppresses some warning when it immediately precedes an expression. https://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html#index-_005f_005fextension_005f_005f In addition, there is a statement expression, which is a different gnu extension. That’s the statements wrapped by ({...}). So the compiler could just ignore __extension__ as it does nothing but suppress warnings. Supporting gnu statement expressions is a different issue and is more difficult.

Documentation on __extension__ seems hard to come by. I found this: https://web.mit.edu/rhel-doc/3/rhel-gcc-en-3/alternate-keywords.html

@WalterBright created dlang/druntime pull request #3735 "fix Issue 22598 - importC: Add support for __extension__ keyword" fixing this issue: - fix Issue 22598 - importC: Add support for __extension__ keyword https://github.com/dlang/druntime/pull/3735

The gcc `({ statement; })` is a whole 'nother thing.

dlang/druntime pull request #3735 "fix Issue 22598 - importC: Add support for __extension__ keyword" was merged into master: - 88538b642b582a8f01a27acb0575dd6679085c0a by Walter Bright: fix Issue 22598 - importC: Add support for __extension__ keyword https://github.com/dlang/druntime/pull/3735