[PATCH] D64671: [clang-tidy] New check: misc-init-local-variables

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added inline comments.


================
Comment at: clang-tools-extra/clang-tidy/misc/InitLocalVariablesCheck.cpp:21
+  Finder->addMatcher(
+      varDecl(unless(hasInitializer(anything()))).bind("vardecl"), this);
+}
----------------
jpakkane wrote:
> alexfh wrote:
> > jpakkane wrote:
> > > alexfh wrote:
> > > > jpakkane wrote:
> > > > > alexfh wrote:
> > > > > > I believe, this should skip matches within template instantiations. Consider this code:
> > > > > > ```
> > > > > > template<typename T>
> > > > > > void f(T) { T t; }
> > > > > > void g() {
> > > > > >     f(0);
> > > > > >     f(0.0);
> > > > > > }
> > > > > > ```
> > > > > > 
> > > > > > What will the fix  be?
> > > > > I tested with the following function:
> > > > > 
> > > > > 
> > > > > ```
> > > > > template<typename T>
> > > > > void template_test_function() {
> > > > >   T t;
> > > > >   int uninitialized;
> > > > > }
> > > > > ```
> > > > > 
> > > > > Currently it warns on the "uninitialized" variable regardless of whether the template is instantiated or not. If you call it with an int type, it will warn about variable t being uninitialized. If you call it with a, say, struct type, there is no warnings. Is this a reasonable approach?
> > > > And what happens, if there are multiple instantiations of the same template, each of them requiring a different fix? Can you try the check with my example above (and maybe also add `f("");`inside `g()`). I believe, the check will produce multiple warnings with conflicting fixes (and each of them will be wrong, btw).
> > > Interestingly it does warn about it, but only once, even if you have two different template specializations.
> > > 
> > > I tried to suppress this warning when the type being instantiated is a template argument type but no matter what I tried I could not get this to work. Is there a way to get this information from the MatchedDecl object or does one need to do something more complicated like going up the AST until a function definition is found and checking if it is a template specialization (presumably with TemplatedKind)? Any help would be appreciated.
> > If there are multiple warnings with the same message at the same location (clang-tidy/ClangTidyDiagnosticConsumer.cpp:745), they will be deduplicated. Thus, a random fix will probably be suggested. The proper way to filter out matches in template instantiations is to add `unless(isInTemplateInstantiation())` to the matcher.
> I tried to make this work but I just could not combine statement and declaration matching in a reliable way. Matching a statement that is not in a template declaration can be done, as well as matching a declaration without intial value, but combining those two into one is hard. After trying many, many things the best I could come up with was this:
> 
> ```
> declStmt(containsDeclaration(0, varDecl(unless(hasInitializer(anything()))).bind("vardecl"))), this)
> ```
> 
> The problem is that `containsDeclaration` takes an integer denoting how manyth declaration should be processed. Manually adding matchers for, say, 0, 1, 2, 3 and 4 works and does the right thing but fails if anyone has an uninitialized variable in the sixth location, things will silently fail.
> 
> The weird thing is that if you do the matching this way, you don't need to filter out things with `unless(isInTemplateInstantiation())`. Maybe statements are handled differently from declarations?
I was struggling to understand, why you want to match a statement, but then I figured out that I should have been more precise: while `isInTemplateInstantiation` only works for `Stmt`s, there's a related matcher that works for `Decl`s: `isInstantiated`. See clang/include/clang/ASTMatchers/ASTMatchers.h:5187. In general, looking into this header can be useful, if you want to find a matcher that you can vaguely describe (e.g. when looking for something related to instantiations, you can search for the relevant substring and find  this and a bunch of other matchers).

Sorry for the confusion. I hope, the suggestion helps.


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64671/new/

https://reviews.llvm.org/D64671