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

[Nico Weber]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uuid.patch
Type: application/octet-stream
Size: 16246 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121004/89f5d7ea/attachment.obj>