gribozavr2 added a comment. I think it makes sense to align the documentation and the definition of IgnoreUnlessSpelledInSource, I'm just not sure which component we should change -- the documentation or the implementation.
Making IgnoreUnlessSpelledInSource not match template instantiations is a nice and simple mental model. However, I'm not sure it is more useful in practice, and here's why. Processing non-instantiated templates is generally very difficult to do correctly: major parts of AST semantics are still unknown, and the parts that can be known are not reliably available. Clang does not provide guarantees about what parts of the template AST are type checked and what are not (I think there are only aspirations), so AST matchers that work in simple tests (where Clang decides to type check more expressions) could fail in more complex templates (where Clang decides to type check less). Generally, processing non-instantiated templates is difficult for the same reasons that make analyzing macro definitions difficult. Analyzing macro definitions is so difficult that tools generally don't do it at all and analyze expansions instead. Analyzing template definitions is more tractable (at least we have some AST nodes), but still, in practice, I'd generally recommend people to analyze template instantiations instead and if they need to perform a refactoring (like renaming a method), trying to cross-reference information across multiple template instantiations. If IgnoreUnlessSpelledInSource is indeed for novice users (and not to be strictly interpreted as "it does what it says") we should think about whether it more useful to ignore instantiations or to match in instantiations. For example, imagine someone who is trying to find usages of a certain function in their codebase by writing a matcher (for example so that they can rename it, or delete as dead code or whatever -- "find usages" is a very common first step). A matcher in IgnoreUnlessSpelledInSource mode that ignores instantiations could find no matches when in fact there are usages from templates. The user deletes the function, and in the best case they get a compilation error (and frustration because the AST matchers lied to them), or in the worst case due to the magic of overload resolution and ADL the code still compiles, but calls a different function that was in the overload set. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80961/new/ https://reviews.llvm.org/D80961 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
