================
@@ -256,35 +256,22 @@ struct Entry {
};
// A conditional expression whose condition itself produces a temporary that
-// needs cleanup (here, the Iter() temporary destroyed by ~Iter) nests the
-// deferred-conditional cleanup of a temporary in one of the conditional's
-// arms inside that condition's cleanup scope. The alloca for the
-// conditionally-destroyed Path temporary must be hoisted out of the outer
-// (full-expr) cleanup scope, even though in the freshly emitted IR its
-// direct parent cleanup scope is the inner one created for the Iter
-// temporary.
-//
-// FIXME: The destruction order below is wrong. Iter() is constructed first and
-// the Path temporary second, so reverse-of-construction order requires ~Path
-// to run before ~Iter, as the OGCG checks show. CIR emits them the other way
-// around because an unconditional cleanup goes on the EH stack and gets its
-// own nested cir.cleanup.scope, whose cleanup region fires when the inner body
-// ends, while a conditional cleanup is deferred to the enclosing
-// full-expression scope and fires later. Mixing the two therefore yields push
-// order instead of reverse-push order.
+// needs cleanup, here the Iter() temporary destroyed by ~Iter. Iter() is
+// constructed before the conditional, so its cleanup scope is the outer one
+// and the conditionally-destroyed Path temporary is destroyed first.
void makeEntry() {
----------------
bcardosolopes wrote:
How about when a temporary created *after* the conditional being destroyed
first, e.g. `f(c ? A() : B(), C())`, or two conditionals in one full expression
with an unconditional temporary between them. Those are the cases where the
scope has to nest outside later temporaries, might be worth covering them.
https://github.com/llvm/llvm-project/pull/225560
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
