[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