[PATCH] Allow per-file clang-tidy options.

Manuel Klimek klimek at google.com
Tue Jun 3 00:33:36 PDT 2014


Comment at: clang-tidy/ClangTidy.cpp:216
@@ -204,1 +215,3 @@
+    Check->setContext(&Context);
+    Check->registerMatchers(&*Finder);
Alexander Kornienko wrote:
> Manuel Klimek wrote:
> > Finder.get()?
> It's a matter of taste. I slightly prefer &*, and &* is used two more times in this file (lines 98, 99) and in other files in clang-tidy. If you have serious reasons to prefer .get() over &*, I can change all of the usages in a separate patch, but now I would like the code to be consistent in this regard.
I'm probably in the "more explicit" camp here - &* will work on anything that's deref'able, .get() will only work on smart-pointer-compatible types. I like the fact that I am able to tell whether &* is just a no-op after a refactoring/replacement that hasn't been noticed (for example, after changing a reference to a pointer variable), or whether it's an intentional retrieval of the pointer.

I don't care too much, so feel free to leave it in.

Comment at: clang-tidy/ClangTidyOptions.h:38-39
@@ +37,4 @@
+struct ClangTidyGlobalOptions {
+  /// \brief Output warnings from certain line ranges of certain files only. If
+  /// this list is emtpy, it won't be applied.
+  std::vector<FileFilter> LineFilter;
Alexander Kornienko wrote:
> Manuel Klimek wrote:
> > I think the second sentence doesn't help. I'd delete it.
> I'd leave it, as it's describes a special case. Without special-casing the empty list, the list would be applied always, and the empty list would mean that no warnings will pass the filter.
Interesting. My default interpretation of a filter is "for all filter, take out what it matches", which, if applied with an empty filter, doesn't change anything.
If empty, no warnings will be filtered.
(or something like that)


More information about the cfe-commits mailing list