Add ImportC compiler to dmd

[Walter Bright]

On 5/13/2021 2:04 PM, Iain Buclaw wrote:
> Well, either one of, or two things will happen:
> 
> 1. People will raise bugs against dmd because `gdc foo.c` will be able to 
> compile more code than dmd (and do preprocessing).
> 
> 2. People will raise bugs against gdc because `gdc -finline foo.c bar.d` doesn't 
> inline C functions into bar.
> 
> I meant conflicts will happen if I change the current behavior so make it so the 
> D compiler handles C sources too i.e: `d21 bar.d foo.c -o bar.o`.

Understood.

It's pretty clear that ImportC is not going to be an exact clone of gcc. I've 
been looking over the __attribute__ documentation, and there doesn't even seem 
to be a proper grammar for it.

https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax

There's some wishy-washy wording:

"Where an attribute specifier is applied to a parameter declared as a function 
or an array, it should apply to the function or array rather than the pointer to 
which the parameter is implicitly converted, but this is not yet correctly 
implemented."

"In some other cases, attribute specifiers are permitted by this grammar but not 
yet supported by the compiler."

"At present, ..."

"An attribute specifier list may, in future, be permitted ..."

"at present this is not implemented and they are ignored"

"some laxity is allowed in the placing of attributes"

which is discouraging. There are the other extensions, too.

Ironically, the one gcc extension ImportC can support fully is inline assembler 
:-) as you've already seen to that!

The plan is to do as few gcc C extensions as practical.

As for the user having options, that's why we have multiple D compilers. ImportC 
isn't part of the D language, and so differing flavors of C support is within 
reason.