In the past we had to use DeclContext::makeDeclVisibleInContext to make
friend declarations available for subsequent lookup calls and this way
we could chain (redecl) the structurally equivalent decls.
By doing this we created an AST that improperly made declarations
visible in some contexts, so the AST was malformed.
Since we use the importer specific lookup this is no longer necessary,
because with that we can find every previous nodes.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 42419 Build 42898: arc lint + arc unit
Event Timeline
Hi Gabor,
I have an inline comment for the patch. Otherwise, looks good.
clang/unittests/AST/ASTImporterTest.cpp | ||
---|---|---|
252 | I wonder if ElaboratedType can be a canonical type because it is only a sugar type itself. Do we need to handle this case? |
clang/unittests/AST/ASTImporterTest.cpp | ||
---|---|---|
252 | You are right, I removed this case. Thanks! |
This broke the windows LLDB bot:
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/11751
Looks like this breaks building on Windows in general: http://45.33.8.238/win/4247/step_4.txt
Recommited in bc5b7e21e32 . I changed llvm:is_contained to a simple for loop over the lookup result. This way the copy assignment of the iterator is avoided even if windows STL is used.
llvm::is_contained?