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 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. https://reviews.llvm.org/D43576 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
