[PATCH] D32751: [ASTImporter] Support new kinds of declarations (mostly Using*)
Peter Szecsi via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Sun May 28 15:32:39 PDT 2017
szepet added a comment.
Some nits added, other than these it looks good to me. Thank you!
Just more one question, I can see 3 different cases how the import returns are handled:
- if(!ToDecl) return nullptr;
- if(!ToDecl && FromDecl) return nullptr;
- no handling: ObjectXY::Create(...Import(FromDecl))
My question is the following: which cases require a check and which decls can be imported without checking the return value of the **import **function?
(Yepp, it could be asked in more general about the Importer, since things like this would be great to follow a convention. I have found some cases where it was not obivous to me which way to check. )
================
Comment at: lib/AST/ASTImporter.cpp:2993
+ return nullptr;
+ }
+
----------------
nit: As I see these cases typically handled in the way:
```
FrPattern = .;
ToPattern = ..;
if(FrPattern && !ToPattern)
```
Just to avoid the nested ifstmt.
================
Comment at: lib/AST/ASTImporter.cpp:3000
+ else
+ // FIXME: We return a nullptr here but the definition is already created
+ // and available with lookups. How to fix this?..
----------------
I dont see the problem with moving these up , collect nad investigate them in a smallset before the Create function, then adding them to the created ToUsing decl. It could be done as a follow up patch, dont want to mark it as a blocking issue.
================
Comment at: lib/AST/ASTImporter.cpp:3042
+ return nullptr;
+ }
+
----------------
the same nit as above
================
Comment at: lib/AST/ASTImporter.cpp:3043
+ }
+
+ LexicalDC->addDeclInternal(ToShadow);
----------------
Does not this causes the same FIXME problem as above?
https://reviews.llvm.org/D32751
More information about the cfe-commits
mailing list