[cfe-commits] [patch] Add codegen support for __uuidof
thakis at chromium.org
Wed Oct 3 19:43:14 PDT 2012
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:
>>>> 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
>>>> 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.
More information about the cfe-commits