I think there were issues with trailing arrays, which is why Clang ended up
settling on this pattern in the first place. Barring significant changes, I
think wrapping this up with some library code is the way to go. That's kind of
what we were thinking with getTrailingObjects(). :-)
I think for the oddball cases like multiple trailing arrays, we can do stuff
like this:
FunctionTemplateDecl * const *getTemplates() const {
return
getTrailingObjects<FunctionTemplateDecl*const>(&getTemplateArgs()[NumArgs-1]);
}
In general, we probably want to lay out trailing arrays in order of higher
alignments to lower alignments to avoid the extra alignment code, and if we get
it wrong, the wrapper will tell us.
For the DeclRefExpr::getFoundDeclInternal() case, I could see adding some kind
of wrapper struct with 8 byte alignment around the found found Decl pointer.
As far as documentation goes, I'd rather update the Doxygen to indicate which
classes have trailing data. Most of the commonly used classes like DeclRefExpr
are already annotated as such.
Another benefit of the getTrailingObjects wrapper is that we can static_assert
that the class with trailing data is `final`.
In conclusion, I guess I would like to push for this wrapper. It seems like it
moves incrementally closer towards the better end state that you want, which is
less pointer arithmetic and casts sprinkled across the AST. Sound reasonable?
http://reviews.llvm.org/D10272
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
