[PATCH] D26455: Handle non-inlined clang::Type::getAs specializations in extract_symbols.py

Stephan Bergmann via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 11 06:55:45 PST 2016


sberg added inline comments.


================
Comment at: utils/extract_symbols.py:210
     # definition is public
+    elif symbol == '_ZNK5clang4Type5getAsINS_14AttributedTypeEEEPKT_v' \
+         or symbol == '_ZNK5clang4Type5getAsINS_26TemplateSpecializationTypeEEEPKT_v' \
----------------
john.brawn wrote:
> sberg wrote:
> > john.brawn wrote:
> > > Same here, though here you can just check that the symbol starts with _ZNK5clang4Type5getAs.
> > We still want to filter out the majority of clang::Type::getAs intstantiations (as they're implicit instantiations of the inline function template), so I thought listing the three symbols explicitly in the two should_keep_*_symbol functions is the best way. An alternative would be to use a regex that matches just those three cases---I can do that change if you prefer it that way.
> My concern here is that if things change in the future (e.g. more specializations of clang::Type::getAs are added in the future) then the code here would have to change, but a regex would hopefully be more robust. Also from a quick check (nm clang | grep 4Type5getAs | wc -l) there are 37 instances of this function, which isn't many.
"My concern here is that if things change in the future (e.g. more specializations of clang::Type::getAs are added in the future) then the code here would have to change": as it would have to when other non-inline explicit specializations are added; those are apparently always special cases that need some sort of manual maintenance here (unless all function template instantiations should be "filtered in")

"but a regex would hopefully be more robust":  more robust in what sense?

"there are 37 instances of this function, which isn't many": I'm not sure I get what you want to imply with that (that it would be OK to "filter in" all 37 of them, implicit instantiations as well as explicit specializations?)


https://reviews.llvm.org/D26455





More information about the llvm-commits mailing list