This fixes unsupporting of importing TypeTraitExpr in ASTImporter.
TypeTraitExpr is caused by "__builtin_types_compatible_p()" that is usually used in the assertion in C code.
For example, PostgreSQL uses the builtin function in its assertion, and ASTImporter currently fails to import the assertion because of diag::err_unsupported_ast_node.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Hello Takafumi,
Thank you for this patch! I feel positive about it. You can find my comments inline.
lib/AST/ASTImporter.cpp | ||
---|---|---|
5540 ↗ | (On Diff #121853) | We should fail (return nullptr) if import fails and ToTI is nullptr. |
5543 ↗ | (On Diff #121853) | No need to create an ArrayRef - SmallVector can be implicitly converted to it so you can just pass SmallVector to the function. |
5545 ↗ | (On Diff #121853) | The style looks a bit broken. Could you clang-format? |
5551 ↗ | (On Diff #121853) | This will assert if E is value-dependent. You need to check it explicitly. |
Hello, Aleksei.
I'm sorry for the long response time.
I update the diff to follow your comments.
Updates
- I apply clang-format -style=llvm to ASTMatchers.h and ASTImporter.cpp. I don't apply it to ASTImporterTest.cpp for readability of the matching types.
- I add return nullptr; if ToTI is nullptr.
- I directly pass ToArgVec to TypeTraitExpr::Create()
- I add a check for the value-dependent of `E'.
Description of the Sema::BuildTypeTrait()
lib/AST/ASTImporter.cpp | ||
---|---|---|
5631 ↗ | (On Diff #123539) | According to Sema::BuildTypeTrait() in lib/Sema/SemaExprCXX.cpp, ExprResult Sema::BuildTypeTrait(TypeTrait Kind, SourceLocation KWLoc, .... bool Dependent = false; for (unsigned I = 0, N = Args.size(); I != N; ++I) { if (Args[I]->getType()->isDependentType()) { Dependent = true; break; } } bool Result = false; if (!Dependent) Result = evaluateTypeTrait(*this, Kind, KWLoc, Args, RParenLoc); return TypeTraitExpr::Create(Context, ResultType, KWLoc, Kind, Args, RParenLoc, Result); ... |
Hello Aaron,
This patch is OK for me but could you please take a look at ASTMatchers changes?
The checker documentation should be updated as well.
include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
2251 ↗ | (On Diff #123539) | Note that the matchers are no longer defined in the header. They are just declared and the definition is moved to a cpp file. |
Hello Gábor,
Thank you for responding.
I move the definition of the mather typeTraitExpr into unittests/AST/ASTImporterTest.cpp.
I also slightly modify the test code.
lib/AST/ASTImporter.cpp | ||
---|---|---|
5622 ↗ | (On Diff #123792) | By the way, you can replace the loop with ImportContainerChecked(). |
Hello there,
I update the diff, reflecting the comments.
Updates:
- Use ImportContainerChecked() for importing TypeSourceInfo.
- Modify bool ToValue = (...) ? ... : false;.
- Add a test case for the value-dependent TypeTraitExpr.
Hello Takafumi,
This is almost OK to me but there is an inline comment we need to resolve in order to avoid Windows buildbot failures.
In addition, as Gabor pointed, when we add a new matcher, we need to update matcher documentation as well. To update the docs, you should perform just three steps.
- Rebase your patch onto latest master
- Launch script docs/tools/dump_ast_matchers.py
- Add changes made by this script to your commit.
After these changes are made, I will approve the patch. Thank you!
unittests/AST/ASTImporterTest.cpp | ||
---|---|---|
554 ↗ | (On Diff #124057) | Please add void f() { declToImport<int>().m(); } after declToImport` definition. The reason is that in MSVC mode, uninstantiated templates are ignored so the test will fail. We need this to avoid this. |
I'm a bit confused -- I don't see any ASTMatcher changes as part of this patch aside from what's in the test file. Are you suggesting the matcher there should be hoisted as a separate patch?
In a previous version the matcher was public. I think it either should be public with documentation or it can remain in the test file and no doc update required. I am fine with both solution.
Oh, sorry! I was thinking that a matcher is still in ASTMatchers.h (in previous revisions it was there). If matcher is internal (current revision), there is no need to update docs.
I'm fine with either exposing it as a public matcher or leaving it private for the test file, but if it gets exposed, I think it should be in a separate patch.
Hello there,
I update the diff and add void f() { declToImport<int>().m(); } after declToImport definition.
I leave the matcher for private in the test file, so I don't update the documentation.
Hello Aaron,
I remove the semicolon.
Is this type actually correct for C++?
Yes, it is.
clang generates the AST for declToImport struct like this.
|-CXXRecordDecl 0x8b19fe0 <col:22, col:29> col:29 implicit struct declToImport `-CXXMethodDecl 0x8b1a0d0 <line:2:3, col:27> col:8 m 'void (void)' `-CompoundStmt 0x8b1a1e8 <col:12, col:27> `-TypeTraitExpr 0x8b1a1c8 <col:14, col:24> '_Bool'
Yeah, it seems as though the ASTDumper does not receive a printing policy, and the default behavior of QualType::getAsString() is to gin up a very dumb printing policy from default language options, hence the poor quality of the name here.
LGTM, thank you!
unittests/AST/ASTImporterTest.cpp | ||
---|---|---|
566 ↗ | (On Diff #124124) | hasType(booleanType())? |