aaronpuchert added a comment.
> Any changes should always be done by adding or removing entries from the
> FactSet, not by mutating the underlying FactEntries.
To make that clearer in the code, I made `FactEntry`s immutable that are
managed by `FactManager` in https://reviews.llvm.org/rC342787.
delesley added a comment.
In https://reviews.llvm.org/D51187#1241354, @aaronpuchert wrote:
> Thanks for pointing out my error! Ignoring the implementation for a moment,
> do you think this is a good idea or will it produce too many false positives?
> Releasable/relockable scoped capabilities th
aaronpuchert added a comment.
Thanks for pointing out my error! Ignoring the implementation for a moment, do
you think this is a good idea or will it produce to many false positives?
Releasable/relockable scoped capabilities that I have seen keep track of the
status, so it makes sense, but mayb
delesley added inline comments.
Comment at: lib/Analysis/ThreadSafety.cpp:929
+ return Handler.handleDoubleLock(DiagKind, entry.toString(), entry.loc());
+Locked = true;
+
It's been a while since I last looked at this code, but I don't think you can
use
aaronpuchert planned changes to this revision.
aaronpuchert added a comment.
This doesn't work with loops yet:
void relockLoop() {
RelockableExclusiveMutexLock scope(&mu);
while (b) {
scope.Unlock(); // releasing mutex 'scope' that was not held
scope.Lock(); // acquirin
