majnemer added a comment.
In https://reviews.llvm.org/D43576#1016512, @rsmith wrote:
> Do we need to also track whether the argument is a pointer or reference to a
> UUID (and also the cv-qualifiers)? For the `Declaration` case, we track this
> by tracking the corresponding parameter type; the same thing would presumably
> work here.
> In https://reviews.llvm.org/D43576#1016295, @majnemer wrote:
> > We should really, really avoid making this sort of change without first
> > trying to desugar uuidof into a reference to a variable. That would solve a
> > ton of problems, problems like this one.
> This desugaring approach is not how we generally do things in Clang. The fact
> that MS exposes a variable that can be named from user code is, in my
> opinion, simply a bug in their implementation -- their implementation details
> are leaking -- and not part of the actual semantics here. I view this as
> exactly analogous to `typeid` (which would have exactly the same problems if
> its result could be used as a non-type template parameter); as with `typeid`,
> `__uuidof` notionally produces a global object not corresponding to any
> variable. If we want to model this as a declaration, we could add a new
> `Decl` subclass for these uuid objects (and eventually also for objects
> produced by `typeid`). But I don't think we should model them as variables
> unless that's actually part of their intended semantics.
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
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. The huge upside I see
from matching their behavior is that the implementation is dramatically
simpler, we have a considerable amount of mumbo jumbo in the template
instantiation code to handle `__uuidof` correctly and it looks like we will
need some more.
What is the relative upside to a new kind of Decl? Better AST fidelity?
cfe-commits mailing list