================
@@ -1710,4 +1710,25 @@ TEST_F(TopTest, ForRangeStmtConverges) {
// analysis converged.
});
}
+
+TEST_F(TopTest, ForRangeStmtHasFlowCondition) {
+ std::string Code = R"(
+ #include <array>
+ void target(bool Foo) {
+ std::array<int, 5> t;
+ for (auto& i : t) {
+ (void)0;
+ /*[[p1]]*/
+ }
+ }
+ )";
+ runDataflow(Code,
+ [](const llvm::StringMap<DataflowAnalysisState<NoopLattice>>
&Results,
+ const AnalysisOutputs &AO) {
+ ASSERT_THAT(Results.keys(), UnorderedElementsAre("p1"));
+ const Environment &Env1 =
getEnvironmentAtAnnotation(Results, "p1");
+
ASSERT_TRUE(Env1.proves(Env1.arena().makeAtomRef(Env1.getFlowConditionToken())));
+ });
+}
----------------
martinboehme wrote:
See comments above -- I'm not sure that the test, if it fails, means that we
need a flow condition for the range-based for. (User code will never be able to
"observe" this flow condition, so I'm not sure why we need it.)
I still don't understand what the underlying purpose is that you need this flow
condition for in the iterator check. Can you expand? (I want to make sure we're
not dealing with an [XY problem](https://en.wikipedia.org/wiki/XY_problem).)
https://github.com/llvm/llvm-project/pull/80989
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
