r175132 - Partially revert r175117 so that we don't break assumptions about how

[John McCall]

On Feb 14, 2013, at 1:58 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> I understand what you're trying to do here, because indeed the standard
>> says that language linkage only applies to functions and variables with
>> external linkage, but I think the right thing to do is to just acknowledge
>> that we (AFAIK, like gcc) just give C language linkage to everything
>> declared in extern "C" and be done with it.  There are much more
>> significant ways in which we deviate from the standard's definition of
>> language linkage.
> 
> That was one of the listed options, and while some callers do want the
> notion of "usable from C", they should be easy to update (mostly going
> from foo.isExternC() to foo.isExternC() &&
> !isExternalLinkage(foo.getLinkage()).
> 
> I don't have a big preference on this, but Richard suggested on IRC
> going the other way: fixing llvm's assumptions about name mangling and
> reverting this patch.

I mean, if LLVM makes non-standard assumptions, we should generally
fix them.  I'm just saying that you're talking about diverging both from the
dominant existing compiler behavior (these assumptions appear to work
on Clang, GCC, and MSVC, and every other random compiler someone's
ever built us with) and a straightforward user expectation (extern "C" just
means "make it look like a C function").  I think that requires some added
justification beyond adherence to a portion of the spec that nobody
implements as specified anyway.

> What are the other deviations from language linkage that you know? The
> one I know in that we don't include it in function types. Do you know
> the rationale for it being what it is on the standard?

My interpretation is that the committee is trying to give implementors
leeway to use a different calling convention for C-linkage functions than
they do for C++ functions.  That would indeed require language linkage
to alter a function type, just like how clang makes calling convention
attributes change the canonical type.

> If we implement what it looks like gcc implements (all variables and
> functions have language linkage), do you think a DR would be reasonable?

If the committee wants to standardize the current behavior of compilers,
that's fine by me.  I don't know whether there are compilers that actually
implement language linkage as creating distinct function types.

John.