aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.
LGTM aside from a minor nit, we can handle the other cases in follow-ups.
================
Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:642
+
+ for (const auto *Init : Ctor->inits()) {
+ const FieldDecl *Member = Init->getMember();
----------------
tbaeder wrote:
> aaron.ballman wrote:
> > Do we have to do anything special if the ctor is an inheriting ctor?
> I have a feeling we do, but I'll tackle inheritance and virtual functions
> later.
Okay, that seems reasonable to me.
================
Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:687
+ return true;
+ } else if (const CallExpr *CE = dyn_cast<CallExpr>(Initializer)) {
+ const Decl *Callee = CE->getCalleeDecl();
----------------
tbaeder wrote:
> aaron.ballman wrote:
> > `CXXMemberCallExpr` as well?
> Yup, that's unhandled here right now it seems, I can add it to this patch or
> add it in a later one.
I'm fine doing it in a follow-up.
================
Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:689
+ const Decl *Callee = CE->getCalleeDecl();
+ const Function *Func = P.getFunction(dyn_cast<FunctionDecl>(Callee));
+
----------------
tbaeder wrote:
> aaron.ballman wrote:
> > What if this comes back as `nullptr` (does `getFunction()` handle that
> > gracefully)?
> It does not :) I was relying on a crash somewhere when I have a test case for
> it.
I'd rather use an explicit `assert` for that instead of relying on a crash;
it's easier to spot the `assert` in that case.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D134057/new/
https://reviews.llvm.org/D134057
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
