Page MenuHomePhabricator

[lldb][NFC] Remove ImportInProgress lock in ClangASTSource

Authored by teemperor on Jun 12 2020, 10:28 AM.



The ClangASTSource has a lock that globally disables all lookups into the external AST source
when we explicitly "guarded" copy a type. It's not used for anything else, so importing declarations
or importing types that are dependencies of a declaration actually won't activate that lock. The
lookups it is supposed to prevent also don't actually happen in our test suite. The check in
ClangExpressionDeclMap::FindExternalVisibleDecls is never executed and the check in
the ClangASTSource::FindExternalVisibleDeclsByName is only ever reached by the
Import-std-module tests (which explicitly do a lookup into the expression context on purpose).

This lock was added in 6abfabff6158076eccdf6fcac5a12894039de2c9 as a replacement for a list
of types we already looked up which appeared to be an optimisation strategy. I assume back then
this lock had a purpose but these days the ASTImporter and LLDB seem to be smart enough to
avoid whatever lookups this tried to prevent.

I would say we remove it from LLDB. The main reason is that it blocks D81561 (which explicitly
does a specific lookup to resolve placeholder types produced by -flimit-debug-info) but it's
semantics are also very confusing. The naming implies it's a flag to indicate when we import
something at the moment which is practically never true as described above. Also the fact
that it makes our ExternalASTSource alternate between doing lookups into the debug info
and pretending it doesn't know any external decls could really break our lookup in some weird way
if Clang decides to cache a fake empty lookup result that was generated while the lock was active.

Diff Detail

Event Timeline

teemperor created this revision.Jun 12 2020, 10:28 AM
teemperor updated this revision to Diff 270573.Jun 13 2020, 5:03 AM
  • Also removed the now unused member variable.
JDevlieghere accepted this revision.Jun 16 2020, 8:22 PM

The variable wasn't even atomic? Good riddance.


This revision is now accepted and ready to land.Jun 16 2020, 8:22 PM

The variable wasn't even atomic? Good riddance.

Actually the whole thing is supposed to be used in a single thread, so that's fine. Just called it a 'lock' as it's like a lock we have active around this one method call (the calls it can block can only come from the same thread as the whole expression parser code doesn't support threads)

labath accepted this revision.Jun 22 2020, 4:34 AM

I don't exactly know what is this protecting against, but removing it definitely makes my life easier.

labath added inline comments.Jun 23 2020, 2:10 AM

You missed this occurence.

teemperor updated this revision to Diff 272660.Jun 23 2020, 3:23 AM
  • Don't initialise the now unused variable.
aprantl accepted this revision.Jun 26 2020, 10:15 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJun 30 2020, 4:19 AM