martong added inline comments.

================
Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h:435
+  /// If the call returns a C++ record type then the region of its return value
+  // can be retrieved from its construction context.
+  Optional<SVal> getReturnValueUnderConstruction(unsigned BlockCount) const;
----------------
balazske wrote:
> A `/` is missing (or too much of `/` above?).
> It looks like that the comment tells something about how the function works, 
> not what it does. Or not? (The function works by retrieving the construction 
> context and something from it, but that seems to be the return value, not a 
> region. This is why this comment can be confusing.) This belongs better to 
> the implementation, not to the documentation part. The documentation could 
> contain something about how and when the function can be used to get a 
> non-null value.
+1

I'd expect a description about what it does and only then the details.


================
Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h:689
 
+  /// Update the program state with all the path-sensitive information
+  /// that's necessary to perform construction of an object with a given
----------------
Why was it necessary to move this prototype? Is this hunk related at all?


================
Comment at: clang/lib/StaticAnalyzer/Core/CallEvent.cpp:575
+  std::tie(State, RetVal) =
+    
static_cast<ExprEngine*>(&Engine)->handleConstructionContext(getOriginExpr(),
+                                                         getState(),
----------------
baloghadamsoftware wrote:
> This is extremely ugly and was one of the reasons I originally did not reuse 
> `handleConstructionContext()`. What should I do here? Create a pure virtual 
> `handleConstructionContext()` into `SubEngine`? Or somehow make 
> `handleConstructionContext` static? Is there maybe a more proper way to 
> access `ExprEngine` from `CallEvent`?
Seems like `SubEngine` has only one descendant: `ExprEngine`. Consequently 
`SubEngine` is a false interface that is never ever used polymorphically, 
perhaps we could just get rid of that? I mean what if we used `ExprEngine` 
everywhere and scraped the `SubEngine` class? `SubEngine` seems to be a 
superfluous legacy to me (I can be wrong of course).


================
Comment at: 
clang/unittests/StaticAnalyzer/TestReturnValueUnderConstruction.cpp:29
+    Optional<SVal> RetVal = Call.getReturnValueUnderConstruction(0);
+    assert(RetVal);
+    assert(RetVal->getAsRegion());
----------------
I think it would make the tests cleaner if we had some member variables set 
here and then in the test function 
(`addTestReturnValueUnderConstructionChecker`) we had the expectations on those 
variables.
Right now, if we face an assertion it kills the whole unit test suite and it is 
not obvious why that happened.


================
Comment at: 
clang/unittests/StaticAnalyzer/TestReturnValueUnderConstruction.cpp:47
+  EXPECT_TRUE(runCheckerOnCode<addTestReturnValueUnderConstructionChecker>(
+                  "class C { public: C(int nn): n(nn) {} virtual ~C() {} "
+                  "          private: int n; };"
----------------
Please clang-format test code as well! You may also use raw string literals. 
Please be precise with test code too.


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

https://reviews.llvm.org/D80366



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to