Move DWARFImporterDelegate into ClangImporter and remove DWARFImporter. #26648
Conversation
adrian-prantl
force-pushed
the
rm-dwarfimporter
branch
from
4078d67 to
8c1d450
Compare
|
test with apple/swift-lldb#1884 |
|
This doesn't even compile yet, but it shows the direction I'm going, in case someone has early feedback. |
This refactors DWARFImporter to become a part of ClangImporter, since it needs access to many of its implementation details anyway. The DWARFImporterDelegate is just another mechanism for deserializing Clang ASTs and once we have a Clang AST, the processing is effectively the same.
adrian-prantl
force-pushed
the
rm-dwarfimporter
branch
from
8c1d450 to
c08a627
Compare
adrian-prantl
changed the title
|
This is good to go now. |
|
test with apple/swift-lldb#1884 |
| if (!swift::ModuleDecl::matchesAccessPath(accessPath, name)) | ||
| return; | ||
|
|
||
| if (lookupKind != NLKind::QualifiedLookup) |
There was a problem hiding this comment.
This is something I meant to ask: What does an unqualified lookup mean in this function?Based on the name I would expect an unqualified lookup to also take some form of context that the unqualified name is relative to, but I don't see that (or is that the access path?). Does this mean something different?
There was a problem hiding this comment.
This is about how the lookup was originally written: was it Module.Foo, or just Foo and we haven't found anything in the current module? The only real reason we have it is so that the magic Builtin module can refuse to provide results for unqualified lookup.
This refactors DWARFImporter to become a part of ClangImporter, since
it needs access to many of its implementation details anyway. The
DWARFImporterDelegate is just another mechanism for deserializing
Clang ASTs and once we have a Clang AST, the processing is effectively
the same.