================
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor<Derived>::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+ auto TSK = D->getTemplateSpecializationKind();
\
/* For implicit instantiations ("set<int> x;"), we don't want to
\
recurse at all, since the instatiated template isn't written in
\
the source code anywhere. (Note the instatiated *type* --
\
set<int> -- is written, and will still get a callback of
\
TemplateSpecializationType). For explicit instantiations
\
("template set<int>;"), we do need a callback, since this
\
- is the only callback that's made for this instantiation.
\
- We use getTemplateArgsAsWritten() to distinguish. */
\
- if (const auto *ArgsWritten = D->getTemplateArgsAsWritten()) {
\
- /* The args that remains unspecialized. */
\
- TRY_TO(TraverseTemplateArgumentLocsHelper(
\
- ArgsWritten->getTemplateArgs(), ArgsWritten->NumTemplateArgs));
\
+ is the only callback that's made for this instantiation. */
\
+ if (TSK != TSK_ImplicitInstantiation) {
\
----------------
hvdijk wrote:
Thanks. It doesn't seem like the same situation as `TraverseFunctionHelper` to
me: there, the logic is that if it's an implicit instantiation, that
instantiation isn't written in the source code anywhere, so should be skipped
by AST traversal. But the check in `TraverseFunctionHelper` assumes we possibly
did end up in an implicit instantiation anyway, and then it needs to be handled
in some appropriate way. Still, I think you're probably right that this should
check `TSK_Undeclared` as well. I don't think that can be covered by this
clang-tidy check, but I can at least check that it doesn't break any other
tests.
https://github.com/llvm/llvm-project/pull/110899
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
