[cfe-dev] extern "C" support

[Mike Stump]

On Jan 3, 2008, at 1:10 PM, Bjørn Roald wrote:
>> -ast-print uses that information to print the ast. Absent that  
>> information we can't faithfully reproduce the syntax tree.  Do we  
>> care that the printed ast is wrong?  Do we care if the ast isn't  
>> actually an ast?

> Does this support nested linkage specifiers as well?

I don't see why it would not, though, I didn't test it.  I did write  
it to work in general, including that case.

[ testing ] Yup, works just fine.

> Should we not let support for linkage be a backend issue (e.g. llvm  
> CodeGen), not frontend, as it is now, the AST is unusable for  
> backends supporting linking to other languages.

There is an extra not above...

> 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 did postpone it out of the parser so that one could have a parser  
parse the above, if they wanted.  :-)