a_sidorin added a comment.
Hi Shafik,
Please find my answers inline.
================
Comment at: lib/AST/ASTImporter.cpp:3243
+
+ if (R) {
+ CXXDestructorDecl *ToDtor = cast<CXXDestructorDecl>(*R);
----------------
shafik wrote:
> a_sidorin wrote:
> > It's better to move this code to VisitFunctionDecl to keep all related
> > stuff together.
> I am not sure I agree. Having everything in `VisitFunctionDecl` makes this
> code harder to maintain.
>
>
That's true, but I think it's better to put FunctionDecl refactoring as a
separate commit - it would be bigger than just putting some related stuff to
the original function. We have the same problem with VisitRecordDecl, but,
unfortunately, I still had no time to rearrange this stuff.
================
Comment at: lib/AST/ASTImporter.cpp:3246
+
+ auto Imp = importSeq(const_cast<FunctionDecl *>(D->getOperatorDelete()),
+ D->getOperatorDeleteThisArg());
----------------
shafik wrote:
> a_sidorin wrote:
> > Moving this code to VisitFunctionDecl will also allow us not to create a
> > dtor if this import fails.
> At what point in `VisitFunctionDecl` would you expect this change to bail out
> of? A possible refactor would be to move this code to a separate function and
> then call that function at that point in `VisitFunctionDecl`. This would
> prevent `VisitFunctionDecl` from becoming even larger and I think address
> your concern.
Just before line 3096, where a new dtor decl is being created.
If correct import of operator delete is required for successful import of dtor
decl, it's better to check if it can be imported before a new dtor decl is
created. So, it's better to put operator delete import before the creation of
a new declaration which is located in VisitFunctionDecl(). Otherwise, we will
be able to create a declaration both invalid and available by AST lookup
(because DeclContexts are already set).
Please correct me if I'm wrong.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56651/new/
https://reviews.llvm.org/D56651
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
