[PATCH] D144164: [clang][Interp] Handle PtrMemOps

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jul 20 07:05:45 PDT 2023


aaron.ballman added inline comments.


================
Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:213-214
 
+  if (BO->isPtrMemOp())
+    return this->visit(RHS);
+
----------------
tbaeder wrote:
> aaron.ballman wrote:
> > Do we need similar changes for unary operators, pointer arithmetic operators, etc?
> In what case would we need similar changes for those?
I could use some more explanation for the changes here then; I thought this was to support overloaded binary operators. e.g.,
```
struct S {
  virtual constexpr int operator+(S s) const {
    return 12;
  }
};

struct T : S {
  constexpr int operator+(S s) const override {
    return 100;
  }
};

constexpr T t1, t2;
constexpr const S &s1 = t1, &s2 = t2;
constexpr const S s3, s4;
static_assert(s1 + s2 == 100);
static_assert(s3 + s4 == 12);
```


================
Comment at: clang/lib/AST/Interp/Context.cpp:121
+  if (T->isFunctionPointerType() || T->isFunctionReferenceType() ||
+      T->isFunctionProtoType())
+    return PT_FnPtr;
----------------
tbaeder wrote:
> aaron.ballman wrote:
> > `isFunctionType()` in general?
> You mean additionally to those or as a replacement? `isFunctionType()` return false for function pointers it seems.
I mean instead of `T->isFunctionProtoType()`; a function without a prototype is still a kind of FnPtr, right? (moot for C++ constexpr, but I'm wondering why there's a requirement for a prototype or whether that's an oversight)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144164/new/

https://reviews.llvm.org/D144164



More information about the cfe-commits mailing list