Alexander_Droste added a comment. > Yes, less boilerplate code needed to work with AST matchers, powerful clang > diagnostic infrastructure is used to report errors, also the add_new_check.py > script ;)
Pretty convincing advertisement line :). > If this class stays in the static analyzer, the clang-tidy check code could > probably just depend on the relevant library and use this class? Sounds straightforward. > That's not a 100% necessary step (you can always add a matcher for > translationUnitDecl() and then traverse the AST using a RecursiveASTVisitor, > for example), but this usually results in a more compact and easy to > understand code. I guess, in case I need to rewrite the code, I just wanted to know how the AST-Matchers work anyway. :) > Clang-tidy checks should also be backed by tests ;) I kind of assumed that I need to rewrite the tests if the implementation gets changed. I'll finish with the path-sensitive checks first and will submit the patch for the AST-based checks to clang-tidy after that. Thanks for offering a review! http://reviews.llvm.org/D12761 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
