[ms-mode] Delayed parsing for a UnaryExprOrTypeTraitExpr?

Hi All,

I’ve been attempting to find a clean way of dealing with an issue parsing the core MS ATL headers in clang. The issue is a missing typename keyword in a sizeof expression containing a dependent name in the header atlstr.h. Annoyingly, this is the last error I’m encountering in the core MS headers.

A simplified example is:

template

size_t GetSize() {

return sizeof(T::SubType); // Should have typename keyword

}

struct TestStruct {

typedef int SubType;

};

void test_typename_missing_msext() {

GetSize();

}

This passes in MSVC as it leaves almost all template evaluation until instantiation by which time it can deduce if T::SubType refers to a typename or a static member.

Clang does the right thing and relies on the typename keyword to decide before institution whether the dependent expression refers to a type or a non-type member. Of note, clang already supports (with warnings) parsing dependent names missing the typename keyword - but only in locations where only a type is permitted (as implemented by Francois in r129425). The problem is dealing with a sizeof expression where the ambiguity cannot be resolved until instantiation.

So, in short are there any safe approaches I could take with this (with a view to patching clang)? From my perspective it looks like there needs to be a third “delayed evaluation” state for UnaryExprOrTypeTraitExpr in order to support MicrosoftMode correctly. Or even a new DelayedUnaryExprOrTypeTraitExpr for MicrosoftMode. Does this sound reasonable or is there a better approach?

  • Will.

I suggest that when transforming a UnaryExprOrTypeTraitExpr, you look
for the case where the operand is a ParenExpr containing a
DependentScopeDeclRefExpr, perform the lookup into the dependent
scope, and if it resolves to a type then produce that type (and a
warning in MS mode / error outside MS mode).

Hi Richard,

Thanks for the initial suggestion. I’ve implemented it locally to prototype the changes required but I’d like a second opinion on how best to structure the code.