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

[Manuel Klimek]

lg

================
Comment at: clang-tidy/ClangTidy.cpp:216
@@ -204,1 +215,3 @@
+    Check->setContext(&Context);
+    Check->registerMatchers(&*Finder);
     Check->registerPPCallbacks(Compiler);
----------------
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.
Perhaps:
If empty, no warnings will be filtered.
(or something like that)

http://reviews.llvm.org/D3979