================ @@ -0,0 +1,84 @@ +//===----------------------------------------------------------------------===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#include "clang/Tooling/DependencyScanning/InProcessModuleCache.h" + +#include "clang/Serialization/InMemoryModuleCache.h" +#include "llvm/Support/AdvisoryLock.h" + +#include <mutex> + +using namespace clang; +using namespace tooling; +using namespace dependencies; + +namespace { +class ReaderWriterLock : public llvm::AdvisoryLock { + // TODO: Consider using std::atomic::{wait,notify_all} when we move to C++20. + std::unique_lock<std::shared_timed_mutex> OwningLock; + +public: + ReaderWriterLock(std::shared_timed_mutex &Mutex) + : OwningLock(Mutex, std::defer_lock) {} + + Expected<bool> tryLock() override { return OwningLock.try_lock(); } + + std::error_code unsafeMaybeUnlock() override { + // Unlocking the mutex here would trigger UB and we don't expect this to be + // actually called when compiling scanning modules due to the generous + // default timeout of 90 seconds. + return {}; ---------------- jansvoboda11 wrote:
I think we should either implement this properly, or never allow timing out in `waitForUnlockFor()`. The latter would probably be super confusing for clients, so I'm leaning towards the former. Opinions? https://github.com/llvm/llvm-project/pull/129751 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
