This is an archive of the discontinued LLVM Phabricator instance.

[clang][deps] NFC: Move `ResourceDirectoryCache`
AbandonedPublic

Authored by jansvoboda11 on Aug 17 2021, 9:41 AM.

Details

Summary

The ResourceDirectoryCache is useful not only in the clang-scan-deps CLI tool, but also in the downstream libclang API. This NFC patch moves it to DependencyScanningService.h. to make it reusable.

Diff Detail

Event Timeline

jansvoboda11 requested review of this revision.Aug 17 2021, 9:41 AM
jansvoboda11 created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptAug 17 2021, 9:41 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
dexonsmith requested changes to this revision.Aug 17 2021, 10:50 AM

I don't think this should be reused. If I'm reading the code correctly, this is just a super heavyweight (but cached) call to Driver::GetResourcesPath(). It should probably be deleted instead.

I suggest instead:

  1. Use Driver::GetResourcesPath() directly in the libclang application.
  2. Figure out if it's safe to do that here as well, and if so, delete this and use it here.

Regarding "is it safe?", the question is whether we expect the clang-scan-deps to be built from the same sources as the clang it's scanning for. I think we do. We're relying on that already for the results of the scan to be correct.

clang/tools/clang-scan-deps/ClangScanDeps.cpp
422–423

This is likely much faster, since it avoids a lock:

assert(!Args.empty());
std::string ResourceDir = Driver::GetResourcePath(Args[0]);

But if the string operations turn out to be expensive we could add caching on top.

Unless, is it supported/expected for clang-scan-deps to be from a different toolchain than clang?

424–427

I assume this is for performance (to avoid doing the filesystem search in each invocation)? If so, please add a comment explaining that.

This revision now requires changes to proceed.Aug 17 2021, 10:50 AM
jansvoboda11 abandoned this revision.Aug 19 2021, 5:15 AM

Fair points. Abandoning in favor of D108366.