[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