[clang] [clang][Interp] Handle complex values in visitBool() (PR #79452)

via cfe-commits cfe-commits at lists.llvm.org
Mon Feb 19 08:02:13 PST 2024


================
@@ -2120,8 +2074,15 @@ bool ByteCodeExprGen<Emitter>::visitInitializer(const Expr *E) {
 template <class Emitter>
 bool ByteCodeExprGen<Emitter>::visitBool(const Expr *E) {
   std::optional<PrimType> T = classify(E->getType());
-  if (!T)
+  if (!T) {
+    // Convert complex values to bool.
+    if (E->getType()->isAnyComplexType()) {
+      if (!this->visit(E))
+        return false;
+      return this->emitComplexBoolCast(E);
+    }
----------------
sethp wrote:

This feels a little odd: I wonder if Sema opts not to insert a `*ComplexToBoolean` cast because "in C, we might not have Boolean"? Though I'm not sure if there's any situation where we would have `_Complex` but not `_Bool`. I know gcc opts to extend support for complex types "backwards" in time as an extension (i.e. under a different name), but I think it also does so for booleans too. Maybe clang has a similar policy?

Put another way, this feels like the sort of "deep" implicit logic (i.e. that's not apparent from the AST) which keeps tripping me up when working with the evaluator in `ExprConstant`; it seems to me like it should either be in Sema (i.e. there ought to be a `*ComplexToBoolean` cast node) or maybe one level up in Visit[Conditional/Ternary/etc.] (whatever there's an implicit boolean context).

I'm just a [dog at a keyboard](https://en.wikipedia.org/wiki/On_the_Internet%2C_nobody_knows_you're_a_dog), though, so take my very much non-expert opinion for what it's worth.



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


More information about the cfe-commits mailing list