rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.
Looks like a really nice cleanup, thanks!
================
Comment at: include/clang/AST/DeclTemplate.h:47-49
@@ -45,3 +46,5 @@
/// derived classes.
-class LLVM_ALIGNAS(/*alignof(void*)*/ LLVM_PTR_SIZE) TemplateParameterList {
+class LLVM_ALIGNAS(/*alignof(void*)*/ LLVM_PTR_SIZE) TemplateParameterList
final
+ : private llvm::TrailingObjects<TemplateParameterList, NamedDecl *> {
+
/// The location of the 'template' keyword.
----------------
I've used that trick in the past to work around the same bug in older versions
of GCC; I think it should work OK (but we're getting into known-weird corners
of MSVC record layout). Doing that in a follow-up change seems fine to me.
================
Comment at: lib/AST/Decl.cpp:3122
@@ +3121,3 @@
+ void *Buffer = Context.Allocate(
+ totalSizeToAlloc<TemplateArgumentLoc, FunctionTemplateDecl *>(
+ TArgs.size(), Ts.size()));
----------------
OK, I guessed that might be the reason. Seems like a reasonable safety measure.
(Do you get an error if you specify the wrong types?)
================
Comment at: lib/AST/DeclTemplate.cpp:554-557
@@ -556,5 +553,6 @@
+ getTrailingObjects<std::pair<QualType, TypeSourceInfo *>>();
for (unsigned I = 0; I != NumExpandedTypes; ++I) {
- TypesAndInfos[2*I] = ExpandedTypes[I].getAsOpaquePtr();
- TypesAndInfos[2*I + 1] = ExpandedTInfos[I];
+ TypesAndInfos[I].first = ExpandedTypes[I];
+ TypesAndInfos[I].second = ExpandedTInfos[I];
}
}
----------------
I'd prefer a placement new expression here rather than calling the assignment
operator on an uninitialized `QualType` object.
http://reviews.llvm.org/D11298
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
