Implement full import of macro expansion info with spelling and expansion locations.
Details
Diff Detail
- Repository
- rC Clang
Event Timeline
The split-token case should be covered by this, because it takes the correct TokenLen and the isTokenRange flag. Other than that the split-token ExpansionInfo is indistinguishable.
What about loaded source locations? Do they need to be handled specifically or does this cover everything now?
This patch is really useful and LGTM!
Just found some minor things.
lib/AST/ASTImporter.cpp | ||
---|---|---|
7193 | Let's say we import a SourceLocation with ASTImporter::Import(SourceLocation FromLoc). | |
unittests/AST/ASTImporterTest.cpp | ||
1580 | Perhaps it would be more concise and less error prone to use a FullSourceLoc which wraps one simple SourceLocation and a SourceManager. | |
1616 | CompareSourceRanges(FullSourceRange{ToD->getSourceRange(), ToSM}, .. ? |
addressed review comment, but there is nothing like FullSourceRange to improve everything
Adding @balazske and @xazax.hun as reviewers. I think if it gets one more approve then we could merge. I'd like to speed up the things here ... we can't expect Aleksei to review all those many patches we sent lately.
unittests/AST/ASTImporterTest.cpp | ||
---|---|---|
1593 | This test causes every case for expansion (macro, macro arg) to be executed at import? |
This code is live when reading pchs, correct? Does this have any measurable perf impact on deserializing pchs for, say, Cocoa.h or Windows.h?
I don't know for sure, but it should be used - yes. I have not measured a possible performance impact. Do you have a suggestion how I could do this on a Linux setup?
Note that I did not implement this as nice-to-have feature, but for fixing a concrete issue: https://reviews.llvm.org/D26054#1085413
unittests/AST/ASTImporterTest.cpp | ||
---|---|---|
1593 | Yes, the last DeclRef will be "arg" on the RHS which is a macro argument expansion and the last IntegerLiteral will be the "1" which is a non-argument macro expansion. |
No. The deserialization of a PCH is handled in a completely independent source code (e.g. ASTUnit::LoadFromASTFile). ASTImporter is responsible to merge two ASTs. These ASTs may come from a PCH - deserialized - , or they may be provided by the parser; from the ASTImporer's point of view this is irrelevant. Thus, there is no performance impact on deserialization of PCHs.
ASTImporter is used in LLDB with the command exec when you want to evaluate an expression and during cross translation unit static analysis.
Hi Rafael,
I apologize for the delay in review and hope to get ASTImporter patches reviewed on this weekend.
lib/AST/ASTImporter.cpp | ||
---|---|---|
7188–7189 | 'for to' => 'for the "from" source manager to'? |
Hi Rafael,
I think the patch is great. But, honestly, I have never dealt with SourceLocation machinery closely, so some things are a bit unclear to me.
lib/AST/ASTImporter.cpp | ||
---|---|---|
7193 | If we have a macro referring another macro in the same file, will we import their FileID twice? First, during Import(getSpellingLoc()) and then in this caller? | |
7195 | ToExLocE seems to be unused in the true branch below. Could we move it into 'else' branch? | |
unittests/AST/ASTImporterTest.cpp | ||
1596 | Could you please add a test with nested macros? I.e. #define FUNC_INT void declToImport #define FUNC FUNC_INT FUNC(int a); |
improved code quality; added nested macro test. it "works", but is disabled because it revealed another bug: the function end location is not imported. will send a patch
lib/AST/ASTImporter.cpp | ||
---|---|---|
7193 | That is taken care of by the ImportedFileIDs check. |
'for to' => 'for the "from" source manager to'?