This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Remove ClangASTImporter reference from Target
ClosedPublic

Authored by xiaobai on Jan 17 2020, 12:13 PM.

Details

Summary

Target is one of the classes responsible for vending ClangASTImporter.
Target doesn't need to know anything about ClangASTImporter, so if we
instead have ClangPersistentVariables vend it, we can preserve
existing behavior while improving layering and removing dependencies
from non-plugins to plugins.

Event Timeline

xiaobai created this revision.Jan 17 2020, 12:13 PM
Herald added a reviewer: shafik. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
teemperor requested changes to this revision.Jan 17 2020, 12:56 PM

I wish we could do this without a global map. Also the ClangASTImporter shouldn't have a dependency on Target (I'm actually surprised this compiles without an additional include).

I'm not sure where the perfect place for the Target's ClangASTImporter is, but putting it in the ClangPersistentVariables would solve your problem of getting it out of Target and doesn't need a global map. Also in general the ClangASTImporter of the Target is used for copying stuff to the scratch context, so having it in the ClangPersistentVariables makes some sense.

lldb/include/lldb/Symbol/ClangASTImporter.h
328

unrelated change

This revision now requires changes to proceed.Jan 17 2020, 12:56 PM

Is an AST importer specific to a target? Can we just put it into the Clang AST type system subclass and create it lazily?

I wish we could do this without a global map. Also the ClangASTImporter shouldn't have a dependency on Target (I'm actually surprised this compiles without an additional include).

I'm not sure where the perfect place for the Target's ClangASTImporter is, but putting it in the ClangPersistentVariables would solve your problem of getting it out of Target and doesn't need a global map. Also in general the ClangASTImporter of the Target is used for copying stuff to the scratch context, so having it in the ClangPersistentVariables makes some sense.

Oh, yes, I'm not a fan of the global map either. I agree that ClangASTImporter shouldn't depend on Target but I think that's better than the other way around. I also agree that putting it into ClangPersistentVariables makes some sense. I'll give it a shot and update this when I get the chance. Thanks for pointing that out!

xiaobai updated this revision to Diff 240001.Jan 23 2020, 1:51 PM

Implement @teemperor's suggestion

xiaobai edited the summary of this revision. (Show Details)Jan 23 2020, 1:51 PM
teemperor accepted this revision.Jan 24 2020, 12:57 AM

Is an AST importer specific to a target? Can we just put it into the Clang AST type system subclass and create it lazily?

If ClangASTImporter was stateless I would agree. But as the ClangASTImporter stores and hands out ASTImporters, it has a *lot* of state. So in theory we should only have one in LLDB to not have different state that goes out of sync. That doesn't fully work as the modules and the target are independent, so having 1(target) + N(modules) is the best we can do I think.

Anyway, the current approach moves it into the ClangPersistentVariables (which are part of the TypeSystemClangForExpressions which is the one for the target-unique scratch ASTContext) so this LGTM.

This revision is now accepted and ready to land.Jan 24 2020, 12:57 AM
teemperor added inline comments.Jan 24 2020, 12:58 AM
lldb/include/lldb/Symbol/TypeSystemClang.h
38 ↗(On Diff #240001)

I would also just let this be part of the normal include list without the empty line (or wherever clang format decides to place this).

lldb/source/Plugins/Language/CPlusPlus/BlockPointer.cpp
22

I would just keep this in the include list above and let clang-format do its thing.

xiaobai updated this revision to Diff 240762.Jan 27 2020, 7:59 PM

Sort headers via clang-format

xiaobai marked 2 inline comments as done.Jan 27 2020, 7:59 PM