[cfe-dev] clang trunk: extern "C"/static problem

[Rafael Espíndola]

> The committee has already reaffirmed this once (albeit quite a long time
> ago).
>
> Having just discussed this at length with fellow CWG member James Dennett,
> we think (hopefully James will correct me if I'm misstating something):
>
>  * Relying on the names of internal-linkage symbols does not seem
> particularly reasonable,
>  * The status quo (Clang rejecting the code in question) also seems far from
> ideal,
>  * We are about an order of magnitude below having enough evidence to
> justify a change to the standard,
>  * It's not reasonable for Clang to be permanently non-conforming here.
>
> Based on the above, I'd like to suggest a solution: we teach CodeGenModule
> to keep track of the internal-linkage functions and variables which are
> declared within C language linkage blocks, and when we reach the end of the
> module, for each such name, if (1) we saw exactly one function or variable
> with that name, and (2) that name is not yet defined in the module, we emit
> an internal linkage alias mapping the "expected" name to the mangled name.
>
> This should be a pretty minimal and non-invasive change, and allows us to
> both conform and accept the code in question. Does that seem OK to everyone?

I think I am ok with it. One problem with going this way is that we
don't have any semantic checking for the "sudo language linkage" going
on, so it is not very clear what "declare within C language blocks"
means. For example, should this 'f' be on the list to get an alias?

static void f();
extern "C" {
  void f();
}
void f() {
}
void use() {
  f();
}

Cheers,
Rafael