[cfe-commits] [patch] Add codegen support for __uuidof

[Nico Weber]

Pinging this every day isn't fun for anyone, so I'll stop doing it. If
I don't hear otherwise, I'll land this a week from today.

On Thu, Oct 4, 2012 at 1:39 PM, Nico Weber <thakis at chromium.org> wrote:
> Minor tweak: When using a target where `struct GUID` doesn't have the
> right data layout (say, 64bit OS X), emit a diagnostic instead of
> crashing. See the 10 new lines toward the end of
> CodeGenModule::GetAddrOfUuidDescriptor() for what's new.
>
> On Thu, Oct 4, 2012 at 11:43 AM, Nico Weber <thakis at chromium.org> wrote:
>> And another ping. I think this is mostly right, maybe future comments
>> can be handled in post-commit review?
>>
>> On Wed, Oct 3, 2012 at 12:57 PM, Nico Weber <thakis at chromium.org> wrote:
>>> Any more comments?
>>>
>>> On Tue, Oct 2, 2012 at 2:24 PM, Nico Weber <thakis at chromium.org> wrote:
>>>> On Tue, Oct 2, 2012 at 2:11 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>>>> On Sun, Sep 30, 2012 at 11:56 PM, Nico Weber <thakis at chromium.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> the attached patch adds codegen support for __uuidof. It's fairly
>>>>>> similar to how the RTTI descriptor code works. What __uuidof does:
>>>>>> Structs can be tagged with __declspec(uuid("some string with
>>>>>> numbers")), and after that __uuidof(taggedstruct) returns a IID struct
>>>>>> filled with the numbers from the uuid declspec attribute. See
>>>>>> test/Parser/MicrosoftExtensions.cpp and the included test for more
>>>>>> information.
>>>>>>
>>>>>> I moved GetUuidAttrOfType() out of Sema since codegen now needs it
>>>>>> too. I couldn't find a great place for it -- it's a static function on
>>>>>> CXXUuidofExpr. Since that expression isn't very useful without uuid
>>>>>> attrs, it's a reasonable place for it I think.
>>>>>>
>>>>>> I'm not very familiar with visibilities. WeakAnyLinkage is mostly a
>>>>>> guess, so please check that.
>>>>>>
>>>>>> The name of the symbol generated for __uuidof constants seems to be an
>>>>>> implementation detail, so I just made up a mangling ("__uuid_"
>>>>>> followed by the contents of the uuid, see GetAddrOfIIDDescriptor()).
>>>>>
>>>>> If the linkage is weak, the name matters, because the symbol will be
>>>>> merged with symbols from other compilation units.  You might want to
>>>>> consider marking it internal/constant/unnamed_addr instead, if the
>>>>> address doesn't actually matter; that way, the name is irrelevant, and
>>>>> the compiler and/or linker can still merge them.
>>>>
>>>> Thanks! As far as I can tell that's good enough. Done.