[PATCH] D128747: ISSUE - incorrect -Winfinite-recursion warning on potentially-unevaluated operand #21668

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jun 29 05:55:36 PDT 2022


aaron.ballman added a comment.

Thank you for this fix, it's coming along well! Can you also add a release note to `clang/docs/ReleaseNotes.rst` mentioning the fix?



================
Comment at: clang/lib/Analysis/CFG.cpp:4062
+  //   operand. [...]
+  // We add only potentially evaluated statements to block to avoid
+  // CFG generation for unevaluated operands.
----------------



================
Comment at: clang/lib/Analysis/CFG.cpp:4064-4068
+  if (S && !S->isTypeDependent()) {
+    if (S->isPotentiallyEvaluated()) {
+      return VisitChildren(S);
+    }
+  }
----------------



================
Comment at: clang/test/SemaCXX/typeinfo:1-16
+namespace std {
+  class type_info {
+  public:
+    virtual ~type_info();
+    const char* name() const { return __name; }
+    bool operator==(const type_info& __arg) const {
+     return __name == __arg.__name;
----------------
You should stick this into the place where it's used rather than a separate file, more comments below about why.


================
Comment at: clang/test/SemaCXX/warn-infinite-recursion.cpp:178
+struct Q {
+  virtual ~Q(){};
+};
----------------



================
Comment at: clang/test/SemaCXX/warn-infinite-recursion.cpp:191
+}
\ No newline at end of file

----------------
Please add a newline back to the end of the file.


================
Comment at: clang/test/SemaCXX/warn-infinite-recursion.cpp:3
 
+#include "typeinfo"
+
----------------
appmonster007 wrote:
> `#include <typeinfo>` resulted in 'typeinfo' file not found with <angled> include; use "quotes" instead
Yup, that's actually by design. We don't want to include headers from the system because then we're testing against whatever happens to be installed on the machine running the test, which makes for poor test coverage. What we usually do is put the system header definitions directly into the file under test, or if it's code that's going to be shared by multiple tests, we'll make a file for it in the `Inputs` directory, and tell the `RUN` line to look there when doing an include. Then we always know exactly what we're testing against.

In this case, I'd just lower the `type_info` class into this file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128747



More information about the cfe-commits mailing list