[clang] [clang-tools-extra] [analyzer][clang-tidy][NFC] Clean up eagerly-assume handling (PR #112209)

DonĂ¡t Nagy via cfe-commits cfe-commits at lists.llvm.org
Tue Oct 15 04:11:16 PDT 2024


================
@@ -3742,23 +3742,20 @@ void ExprEngine::evalLocation(ExplodedNodeSet &Dst,
   BldrTop.addNodes(Tmp);
 }
 
-std::pair<const ProgramPointTag *, const ProgramPointTag*>
-ExprEngine::geteagerlyAssumeBinOpBifurcationTags() {
-  static SimpleProgramPointTag
-         eagerlyAssumeBinOpBifurcationTrue(TagProviderName,
-                                           "Eagerly Assume True"),
-         eagerlyAssumeBinOpBifurcationFalse(TagProviderName,
-                                            "Eagerly Assume False");
-  return std::make_pair(&eagerlyAssumeBinOpBifurcationTrue,
-                        &eagerlyAssumeBinOpBifurcationFalse);
+std::pair<const ProgramPointTag *, const ProgramPointTag *>
+ExprEngine::getEagerlyAssumeBifurcationTags() {
+  static SimpleProgramPointTag TrueTag(TagProviderName, "Eagerly Assume True"),
+      FalseTag(TagProviderName, "Eagerly Assume False");
+
+  return std::make_pair(&TrueTag, &FalseTag);
----------------
NagyDonat wrote:

I thought about that, but I don't like global variables (including static members) with not entirely trivial constructors or destructors. I don't think that the initializer of `SimpleProgramPointTag` can cause actual problems (it only does some string concatenation), but it's still a code smell IMO.

Also, I felt that this "get both tags in a single pair, then assign them to short local aliases" interface is better than having two static data members which need to have long names, and referring to e.g. `&EagerlyAssumeBifurcationTrueTag` or something similar.

I'd prefer to keep the current implementation, but I can change it if you strongly prefer a static const member.

https://github.com/llvm/llvm-project/pull/112209


More information about the cfe-commits mailing list