[PATCH] Make UninitializedValues detect the use of uninitialized fields in a constructor.

[Richard Smith]

================
Comment at: lib/Analysis/UninitializedValues.cpp:993
@@ +992,3 @@
+    else if (Optional<CFGInitializer> ci = I->getAs<CFGInitializer>()) {
+      tf.setReportConstructor(isInClassInitializer(ctor, ++initIdx));
+      FieldDecl *fd = ci->getInitializer()->getMember();
----------------
Jordan Rose wrote:
> Richard Smith wrote:
> > This counting approach seems rather complex to me, and I think we can get the same effect with something much simpler: remove the 'ReportConstructor' code entirely, and when you come to issue a diagnostic for an uninitialized use of a field, check whether the source location of the use is within the source range of the constructor. If not, emit the additional note pointing out which constructor it was.
> I'm always iffy about source ranges because of macros. It doesn't seem like it'd be too awful if it misfired here, but at the same time you could notice that the field (a) has an in-class initializer, and (b) does not have an associated initializer. (And calculate the latter with a simple linear walk, since we've already decided to emit an error message.)
`isBeforeInTranslationUnit` does the right thing in the presence of macros (it compares the order of tokens after preprocessing).

================
Comment at: lib/Analysis/CFG.cpp:769-777
@@ -768,2 +768,11 @@
     }
+    if (CXXDefaultInitExpr *Default = dyn_cast<CXXDefaultInitExpr>(Init)) {
+      // Append the actual expression here. The context is not ambiguous here.
+      autoCreateBlock();
+      appendStmt(Block, Default);
+      if (Stmt *Child = Default->getExpr())
+        if (CFGBlock *R = Visit(Child))
+          Block = R;
+      return Block;
+    }
     return Visit(Init);
----------------
Jordan Rose wrote:
> I'm assuming "the context is not ambiguous here" means "we can guarantee that this expression will only appear once in the CFG, unlike when it is used in list-initialization". That's why we didn't do this before.
> 
> It would be nice to have a CFG validator that enforced this "appears-once" restriction, but that can come later.
Exactly; we only expand default initializers when they're (implicitly) used from a constructor initializer list, and each such default initializer can only be used once in any given constructor. Maybe a more detailed comment here would help.


http://llvm-reviews.chandlerc.com/D2181