rsmith added a comment.
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
> 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
cfe-commits mailing list