[cfe-dev] extern "C" support

[Chris Lattner]

On Jan 5, 2008, at 2:14 PM, Mike Stump wrote:

>> This would mean a change of Sema::ActOnLinkageSpec to support more
>> lang_xxx enums and/or  pass the language string to the AST consumer.
>
>> And let the backend codegen emit diagnostics, something similar to
>> pseudocode:
>
>> any thoughts ?
>
> Sure, my thought would be, if one has a plug in for a code generator
> that supports a new language, call it Pascal, if you want, it does
> seem reasonable to have the supported by a previously compiled front
> end.  Do we have such a clean architecture?  There is a cost in that
> though, space, ownership of strings and the like.  Pay now, or pay
> when someone wants the feature, I'll leave that for others to chime in
> with.  Also, if you defer it, do you give up issuing an error when you
> say:
>
> extern "unknown" static int i;
> void foo() {
> }
>
> and i is deleted by the optimizer because it isn't used?  Do we want
> that or not?  Anyway, I'd rather get the entire rest of the core of
> the language done than fiddle the fine details.  If written well, they
> are flexible enough to change.

I completely agree with you Mike.

> I did postpone it out of the parser so that one could have a parser
> parse the above, if they wanted.  :-)

I think that postponing it is the right thing to do.  There is a lot  
more than just "how it gets lowered in the backend" that changes based  
on the extern C.  There is also extra semantic analysis that can go  
along with it ("you can't pass this C++ object into a extern C  
function" or "extern C functions can't take references" or  
something).  At this point, how to handle this is not at all clear,  
and I'd prefer to get the simple stuff working first.

Thanks Mike!

-Chris