[llvm-commits] [PATCH] Suppress "user-defined return type in extern C" warning under Clang

[Aaron Ballman]

On Tue, Feb 14, 2012 at 3:13 PM, Matt Johnson <johnso87 at illinois.edu> wrote:
>
>
> On 02/14/2012 02:56 PM, Aaron Ballman wrote:
>>
>> On Tue, Feb 14, 2012 at 2:50 PM, Matt Johnson<johnso87 at illinois.edu>
>>  wrote:
>>>
>>> On 02/14/2012 02:42 PM, Aaron Ballman wrote:
>>>>
>>>> On Tue, Feb 14, 2012 at 2:28 PM, David Blaikie<dblaikie at gmail.com>
>>>>  wrote:
>>>>>
>>>>> [+aaron who added this warning&    was already looking into the fix for
>>>>> LLVM]
>>>>>
>>>>>
>>>>> Perhaps you've got the right fix - but at least Aaron won't keep
>>>>> working on it redundantly. It looks reasonable to me.
>>>>
>>>> The patch looks like it will work the same for clang as it does for
>>>> MSVC, which is good.  But I'm a bit concerned as to why we have an
>>>> extern "C" function that returns a type that can't be represented in
>>>> C.  Is that the problem we should be solving instead?
>>>
>>> My understanding is that we're declaring these functions as 'extern "C"'
>>> not
>>> to actually call them from C code, but just to avoid mangling.  The
>>> VS2010
>>> docs (http://msdn.microsoft.com/en-us/library/1e02627y.aspx) state that
>>> if
>>> the definition and all calls are *actually* C++ code, doing this is
>>> legal.
>>>  I'm far from an authority on the matter, but it sounds reasonable.
>>
>> That certainly is true, and is reasonable.  :-)  I'm just trying to
>> figure out the "why" part of it.  Why do we not want mangled names in
>> this situation?  If it makes sense, which I'm betting it does, then
>> your fix is great.  If we want non-mangled names for some sort of
>> interoperability, then I think we may want to do something other than
>> suppress the warning.
>
> I'm guessing it's just to make it reasonable to export some common functions
> to interpreted applications without depending on libffi or requiring
> DynamicLibrary::SearchForAddressOfSymbol() to implement mangling or depend
> on libsupc++, libc++abi, or similar (for no obvious benefit other than
> whatever intrinsic ugliness of 'extern "C"'.  lle_X seems like a reasonable
> prefix which doesn't conflict with _Z or other mangling prefixes I'm aware
> of.

Sold!  :-)

Committed in r 150508, thanks for the help!

~Aaron