The analyzer can probably be modified (later) to take advantage of this as 
well. Awesome.


================
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);
----------------
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.

================
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();
----------------
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.)


http://llvm-reviews.chandlerc.com/D2181
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to