[PATCH] D43576: Solution to fix PR27066 - Redefinition with same mangled name as another definition (dllexport and uuid)

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In https://reviews.llvm.org/D43576#1016588, @rsmith wrote:

> In https://reviews.llvm.org/D43576#1016561, @majnemer wrote:
>
> > Here's my thinking: the `__uuidof` expression literally declares a variable called `_GUID_ddb47a6a_0f23_11d5_9109_00e0296b75d3` of type `__s_GUID` which is why it behaves the way it does: https://godbolt.org/g/74FY7U
>
>
> This is an implementation detail leaking, though. no? Note that that is a reserved name.
>
> > I don't think it is reasonable to invent new semantics which are different from the MSVC ones because we find the MSVC ones inelegant.
>
> I mostly agree, but my point is that this is *not* the MSVC semantics, it's merely an implementation detail that non-conforming code happens to be able to observe. Suppose that `type_info` objects were similarly accessible in MSVC by guessing their mangled names. Would you be arguing that we should inject variables for those too? (And note that it is *nearly* true that `type_info` objects work that way: https://godbolt.org/g/zByFFg -- but the parser gets confused somehow when you reference them.) The only difference I can see between these cases is that the reserved name used for the GUID case happens to not contain any ?s and @s, so happens to be utterable as an identifier.
>
> We should not attempt to be compatible with the cases where MSVC's implementation details happen to leak into user-visible semantics.
>
> > What is the relative upside to a new kind of Decl? Better AST fidelity?
>
> Yes, exactly. The same reason we don't desguar other things any more than we have to.


Before I start implementing this I want to make sure that we are on the same page on this.
>From your comments it looks like we do not want to create global variables for the uuid globals. I tend to agree with that. I do like the idea of creating a new Decl type for the uuid declspec. But I want to make sure that I understand what you are referring to.
Currently this declaration:
struct
__declspec(uuid("{DDB47A6A-0F23-11D5-9109-00E0296B75D3}"))
S1;

a CXXRecordDecl type is generated with attributes (the uuid being an attribute). Are you proposing that instead a new type is generated for S1 say something like CXXUuidRecord? And create also a new TagType that corresponds to this new Decl?


https://reviews.llvm.org/D43576