faisalv added a comment. Thanks for working on this bug too!
================ Comment at: lib/Sema/TreeTransform.h:4784 @@ +4783,3 @@ + NewType = getDerived().RebuildPackExpansionType( + NewType, SourceRange(), Loc, NumExpansions); + if (NewType.isNull()) ---------------- Any thoughts on the value of threading EllipsisLoc and PatternRange into this function (they are used primarily for a diagnostic that is triggered in Sema if NewType does not contain an unexpandedparameter pack - which would never get triggered here, so it would be ok to pass in invalid sourelocations and sourceranges with an appropriate comment here) - but the fact that RebuildPackExpandionType is a customization point, it might not be a bad idea to preserve them)? Alternatively, we could forego calling RebuildPackExpansionType - since OldType is decomposed directly into a PackExpansionType -- NewType could be recomposed directly via Context.getPackExpansionType(NewType, NumExpansions=0)? Which brings me to - when we create the new pack expansion type, shouldn't the NumExpansions be reset to 0? The fact that we will have a SubstTemplateParameterType replacing the TemplateParameterType within the pattern might influence the answer to that... Also - we should be able to assert here that *NumExpansions should be one? Can you think of a case that it wouldn't be? http://reviews.llvm.org/D21030 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
