<div dir="ltr">Hi Richard,<div><br></div><div>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.<div class="gmail_extra">
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I suggest that when transforming a UnaryExprOrTypeTraitExpr, you look<br>
for the case where the operand is a ParenExpr containing a<br>
DependentScopeDeclRefExpr, perform the lookup into the dependent<br>
scope, and if it resolves to a type then produce that type (and a<br>
warning in MS mode / error outside MS mode).<br>
</blockquote></div><br>The (very) rough implementation I've inserted in TransformUnaryExprOrTypeTraitExpr() is:</div>
</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"><div class="gmail_extra"> if (SemaRef.getLangOpts().MicrosoftMode) {</div><div class="gmail_extra"><br></div><div class="gmail_extra">
ParenExpr* PE = dyn_cast<ParenExpr>(E->getArgumentExpr());</div><div class="gmail_extra"> DependentScopeDeclRefExpr *DepDecl </div><div class="gmail_extra"> = dyn_cast<DependentScopeDeclRefExpr>(PE ? PE->getSubExpr() : E->getArgumentExpr());</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"> if (DepDecl) {</div><div class="gmail_extra"> NestedNameSpecifierLoc QualifierLoc</div><div class="gmail_extra"> = getDerived().TransformNestedNameSpecifierLoc(DepDecl->getQualifierLoc());</div>
<div class="gmail_extra"> if (!QualifierLoc)</div><div class="gmail_extra"> return ExprError();</div><div class="gmail_extra"><br></div><div class="gmail_extra"> DeclarationNameInfo NameInfo</div><div class="gmail_extra">
= getDerived().TransformDeclarationNameInfo(DepDecl->getNameInfo());</div><div class="gmail_extra"> if (!NameInfo.getName())</div><div class="gmail_extra"> return ExprError();</div><div class="gmail_extra">
<br></div><div class="gmail_extra"> CXXScopeSpec SS;</div><div class="gmail_extra"> SS.Adopt(QualifierLoc);</div><div class="gmail_extra"><br></div><div class="gmail_extra"> // From Sema::BuildQualifiedDeclarationNameExpr()</div>
<div class="gmail_extra"> DeclContext *DC = SemaRef.computeDeclContext(SS, false);</div><div class="gmail_extra"> if (!DC)</div><div class="gmail_extra"> return ExprError();</div><div class="gmail_extra">
<br></div><div class="gmail_extra"> if (SemaRef.RequireCompleteDeclContext(SS, DC))</div><div class="gmail_extra"> return ExprError();</div><div class="gmail_extra"><br></div><div class="gmail_extra"> LookupResult R(SemaRef, NameInfo, Sema::LookupOrdinaryName);</div>
<div class="gmail_extra"> SemaRef.LookupQualifiedName(R, DC);</div><div class="gmail_extra"><br></div><div class="gmail_extra"> if (TypedefNameDecl* TypeDecl = R.getAsSingle<TypedefNameDecl>())</div><div class="gmail_extra">
return getDerived().RebuildUnaryExprOrTypeTrait(TypeDecl->getTypeSourceInfo(),</div><div class="gmail_extra"> E->getOperatorLoc(),</div><div class="gmail_extra">
E->getKind(),</div><div class="gmail_extra"> E->getSourceRange());</div><div class="gmail_extra" style> // TODO: Issue warn_typename_missing</div>
<div class="gmail_extra"> }</div><div class="gmail_extra"> }</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>The code is mostly based on the path TransformExpr() would take when dealing with a <br>
DependentScopeDeclRefExpr which understandably but unfortunately duplicates a lot of the logic.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>My main questions are:</div><div class="gmail_extra" style>
<ul style><li style>Is the amount of code duplication acceptable in this special case?<br></li><li style>Are there any short cuts I'm missing?</li><li style>Should I directly call Sema::BuildQualifiedDeclarationNameExpr() and find a way to reuse the lookup logic?</li>
<li style>I'd like to move the code out of TransformUnaryExprOrTypeTraitExpr() - any method name suggestions?</li><li style>Does changing from err_unexpected_typedef to warn_typename_missing make sense in this case?</li>
</ul></div><div class="gmail_extra" style>Thanks in advance!</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>Will.</div>
</div></div></div>