This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Create a ASTImporterSharedState and pass it to all ASTImporterDelegates
Changes PlannedPublic

Authored by teemperor on Dec 8 2020, 7:37 AM.

Details

Reviewers
martong
a.sidorin
Summary

This patch is just creating an ASTImporterSharedState for each ASTContext we import into
and then pass it to all the different ASTImporter instances that import into that context.

See the ASTImporterSharedState documentation for the benefits of using the shared state.

Diff Detail

Event Timeline

teemperor created this revision.Dec 8 2020, 7:37 AM
teemperor requested review of this revision.Dec 8 2020, 7:37 AM

So the only downside I can see is that the ASTImporter is no longer considering non-imported declarations in the To context (which are not known to the SharedState) for merging? Given that we most likely never want this to happen within LLDB, this seems like a straightforward change.

@martong I assume I can make a follow-up for removing all the ASTImporter code for situations without a shared state?

So the only downside I can see is that the ASTImporter is no longer considering non-imported declarations in the To context (which are not known to the SharedState) for merging?

This is the case if you create the SharedState without a lookup table. If you pass a TUDecl then a lookup table will be created and in the constructor of that we traverse the AST to initialize the lookup. And from that point we will find every existing Decl even if they were not imported. As it is now we'd still be using the old noload_lookup.

@martong I assume I can make a follow-up for removing all the ASTImporter code for situations without a shared state?

Yes, that'd would be super.
Other than that, if you could make sure that the ASTImporterLookupTable is initialized then noload_lookup would not be needed and we could simplify so much in clang::ASTImporter.

lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.h
269

If you want to get rid of noload_lookup in clang::ASTImporter then you have to pass the TranslationUnitDecl to the SharedState's constructor because only in that case would we create the lookup table.

So the only downside I can see is that the ASTImporter is no longer considering non-imported declarations in the To context (which are not known to the SharedState) for merging?

This is the case if you create the SharedState without a lookup table. If you pass a TUDecl then a lookup table will be created and in the constructor of that we traverse the AST to initialize the lookup. And from that point we will find every existing Decl even if they were not imported. As it is now we'd still be using the old noload_lookup.

@martong I assume I can make a follow-up for removing all the ASTImporter code for situations without a shared state?

Yes, that'd would be super.
Other than that, if you could make sure that the ASTImporterLookupTable is initialized then noload_lookup would not be needed and we could simplify so much in clang::ASTImporter.

Hmm, as far as I remember, in the past I tried this. And bumped into some issues, because during the traverse we had to load Decls with external storage and that introduced a new and uncontrolled import...

So the only downside I can see is that the ASTImporter is no longer considering non-imported declarations in the To context (which are not known to the SharedState) for merging?

This is the case if you create the SharedState without a lookup table. If you pass a TUDecl then a lookup table will be created and in the constructor of that we traverse the AST to initialize the lookup. And from that point we will find every existing Decl even if they were not imported. As it is now we'd still be using the old noload_lookup.

@martong I assume I can make a follow-up for removing all the ASTImporter code for situations without a shared state?

Yes, that'd would be super.
Other than that, if you could make sure that the ASTImporterLookupTable is initialized then noload_lookup would not be needed and we could simplify so much in clang::ASTImporter.

Hmm, as far as I remember, in the past I tried this. And bumped into some issues, because during the traverse we had to load Decls with external storage and that introduced a new and uncontrolled import...

Ah, I assumed the default-constructed SharedState would have an empty table, but it has no table. That explains why this works with little modifications...

Anyway, I'm not sure if the workflow of first scanning the TU for all decls makes sense in LLDB. The idea is that we build the TU in the first place with the help of an ExternalSource and the ASTImporter, so once we have an actual TU to scan, we no longer use the ASTImporter.

However, every single TU in LLDB starts being pretty much empty (we do have some dummy declarations in them, but none of them have any name conflicts with declarations in any other AST we import from). So technically the 'empty' LookupTable is accurate.

However, every single TU in LLDB starts being pretty much empty (we do have some dummy declarations in them, but none of them have any name conflicts with declarations in any other AST we import from). So technically the 'empty' LookupTable is accurate.

Okay, that makes sense. So, we could then try to build an empty lookup table in the default constructor of SharedState. This way we could get rid of noload_lookup entirely. And that would indeed result what you suggested at the beginning of our conversation (i.e. the ASTImporter would no longer consider non-imported declarations in the To context for merging). This could work.

teemperor planned changes to this revision.Dec 9 2020, 11:25 AM

There area few failures once I actually create the lookup table, so I put this on my TODO list.