I am planning to submit a talk about ASTImporter to the upcoming Dev Meeting at October 22-23, 2019.
I’d like to talk about
the API,
how it is used in CTU analysis and in LLDB,
internal subtleties and difficulties (Error handling, ExternalASTSource, …)
The goal would be to attract more developers to use and improve ASTImporter related code, so perhaps this will be a tutorial.
Independently from the talk, I’d like to have a round table discussion if there is enough interest.
Some topics could cover future development ideas and existing problems we have.
Please get back to me if you are interested and think about the topics you have in mind, also don’t forget to buy your ticket to the DevMeeting.
At the upcoming LLVM Dev Conf, we will have a round table discussion for ASTImporter, right after the ASTImporter Tutorial.
The time slot for the round table is Wednesday, Oct 23 2:55-4:00.
I have gathered things about possible future work and improvements, bring your own topic to discuss!
Thanks and see you at the conference,
Gabor
Big stuff
Error handling: rollback mechanism
Replace StructuralEquivalency with ODRHash
Step 0: StructuralEquivalency should not diagnose when called from the
Importer, diags should be coming from the importer.
VarTemplateSpecializationDecl: ODR violation is not even detected
Renaming strategy
Strategies for AccumulateChildErrors
Clients of the ASTImporter should be able to choose an
appropriate error handling strategy for their needs. For instance,
they may not want to mark an entire namespace as erroneous merely
because there is an ODR error with two typedefs. As another example,
the client may allow EnumConstantDecls with same names but with
different values in two distinct translation units.
Smaller issues/tasks/FIXMEs (techn debt)
VisitFunctionDecl:
Member function templates are not handled similarly to simple fun
specializations
Thank you guys for coming to the round table. I am trying to summarize what we were talking about.
Error handling: rollback mechanism
We agreed that this is something that would be incredibly problematic to implement mostly because the AST is not designed to be trimmed. In normal cases, the AST just grows, but nodes and interconnections between them are never deleted.
Replace StructuralEquivalency with ODRHash
Step 0: StructuralEquivalency should not diagnose when called from the
Importer, diags should be coming from the importer.
We agreed that the class StructuralEquivalenceContext is used for multiple things in the ASTImporter. These are 1) ODR violation discovery 2) identifying the existing part of a redecl chain for a Decl. Actually, ODR checking is based on tokens if we compare definitions, so structural eq is not the best thing to use for that.
We have concerns whether we could use the ODRHash, but we agreed that it would be worth to prototype it.
ODRViolation handling
Class(Var)TemplateSpecializationDecl: Problem! We can’t have more than 1 spec
(https://reviews.llvm.org/D66999)
We agreed that this is fine to be conservative in case of specializations, in these cases we will always use the existing definition and will report back an error. (In case of simple classes and other non-specialization decls ,however, the liberal strategy can be used.)
Renaming strategy in case of ODR violation
Raphael is worried about name mangling issues that could cause.
Strategies for AccumulateChildErrors
Clients of the ASTImporter should be able to choose an
appropriate error handling strategy for their needs. For instance,
they may not want to mark an entire namespace as erroneous merely
because there is an ODR error with two typedefs. As another example,
the client may allow EnumConstantDecls with same names but with
different values in two distinct translation units.
We agreed that this is fine to use this approach, probably there is no need to make this behavior configurable.
VarTemplateSpecializationDecl: ODR violation is not even detected
We didn’t have time to discuss this.
Smaller issues/tasks/FIXMEs (techn debt)
VisitFunctionDecl:
Member function templates are not handled similarly to simple fun
specializations
We agreed that this is a big technical debt
Merge function definitions of members
We discussed that out-of class default definitions can cause this situation, and at some time we should finish this.
Use PrevDecl in GetImportedOrCreateDecl ?
We agreed that handling of attributes cannot be done with one patch because there are many different inheritable attributes and each must be handled differently.
ObjC/ObjC++ support and stabilization
No test cases (not interesting for E///, we don’t have objc/c++ code)
We agreed that there is a technical debt here, but we did not show much interest in fixing that.
ClassTemplateSpecializationDecl: merge instantiated default arguments,
exceptions specifications
We understood the problem (that took like 20 minutes and AST dumping) and recognized that the way we merge initializers of fields is good, and we should continue doing that with default arg and exceptions spec instantiations.
We did not have time to discuss these other issues:
Structural Eq:
Polluted cache of nonequivalent declarations
Some diagnostics are completely missing, this is misleading
Several minor issues/fixmes with VarTemplateDecl
Check visibility/linkage for ClassTemplateDecl, VarTemplateDecl
Fix import of equivalent but repeated FriendDecls
Handle redecl chain of TypeDefNameDecl
Add Decls to their context in a unified way, and only if the "From"DC
contains it (AddDeclToContexts)
VisitVarDecl:
Check for ODR error if the two definitions have different initializers?
Diagnose ODR error if the two initializers are different