@@ -1359,17 +1361,18 @@ void ThreadSafetyAnalyzer::getMutexIDs(CapExprSet
, AttrType *Attr,
const Expr *Exp, const NamedDecl *D,
const CFGBlock *PredBlock,
https://github.com/dmcardle created
https://github.com/llvm/llvm-project/pull/97293
This PR reverts #95290 and the one-liner followup PR #96494.
I received some substantial feedback on #95290, which I plan to address in a
future PR.
I've also received feedback that because the change emits
dmcardle wrote:
Hi @asmok-g, it was definitely not my intention to break any use cases where
the analysis was behavior properly!
I wanted to verify that the prior release, which predates this change,
understands smart pointer returns on trylock functions, but I'm having trouble
finding a
dmcardle wrote:
@AaronBallman PTAL — looks like #95290 broke the documentation.
https://github.com/llvm/llvm-project/pull/96494
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dmcardle created
https://github.com/llvm/llvm-project/pull/96494
Without a newline, documentation was failing to build with this error:
Warning, treated as error:
https://github.com/dmcardle edited
https://github.com/llvm/llvm-project/pull/95290
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dmcardle updated
https://github.com/llvm/llvm-project/pull/95290
>From 807953fc74920e3d5ed727a00c0e1177870c56fe Mon Sep 17 00:00:00 2001
From: Dan McArdle
Date: Thu, 20 Jun 2024 17:43:16 -0400
Subject: [PATCH] [clang][ThreadSafety] Check trylock function success and
return
https://github.com/dmcardle updated
https://github.com/llvm/llvm-project/pull/95290
>From 66715ea5566946f0608d77dc4c86b23e70179760 Mon Sep 17 00:00:00 2001
From: Dan McArdle
Date: Thu, 20 Jun 2024 17:43:16 -0400
Subject: [PATCH] [clang][ThreadSafety] Check trylock function success and
return
dmcardle wrote:
So... I appear to have accidentally fixed a bug. Looks like enum success values
were not being evaluated, and defaulted to false. As a result, the analysis
could fail to detect unguarded access [[demo on
dmcardle wrote:
> LGTM -- that new documentation is fantastic, thank you for that!
Thank you! I hope it saves future readers some time.
I don't have write access, so feel free to merge unless we're waiting for
@aaronpuchert to review :)
https://github.com/llvm/llvm-project/pull/95290
https://github.com/dmcardle edited
https://github.com/llvm/llvm-project/pull/95290
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dmcardle updated
https://github.com/llvm/llvm-project/pull/95290
>From dc8e7b16d5e7318819e61223aa2fc9f483998806 Mon Sep 17 00:00:00 2001
From: Dan McArdle
Date: Thu, 20 Jun 2024 17:43:16 -0400
Subject: [PATCH] [clang][ThreadSafety] Check trylock function success and
return
@@ -614,9 +619,23 @@ static bool checkTryLockFunAttrCommon(Sema , Decl *D,
const ParsedAttr ,
return false;
}
- // check that all arguments are lockable objects
+ // Check that all remaining arguments are lockable objects.
checkAttrArgsAreCapabilityObjs(S, D, AL,
@@ -614,9 +619,23 @@ static bool checkTryLockFunAttrCommon(Sema , Decl *D,
const ParsedAttr ,
return false;
}
- // check that all arguments are lockable objects
+ // Check that all remaining arguments are lockable objects.
checkAttrArgsAreCapabilityObjs(S, D, AL,
@@ -3657,8 +3657,8 @@ class Foo {
int a GUARDED_BY(mu_);
bool c;
- inttryLockMutexI() EXCLUSIVE_TRYLOCK_FUNCTION(1, mu_);
- Mutex* tryLockMutexP() EXCLUSIVE_TRYLOCK_FUNCTION(1, mu_);
+ bool tryLockMutexI() EXCLUSIVE_TRYLOCK_FUNCTION(1, mu_);
dmcardle wrote:
Just force-pushed what I described in the last comment.
1. Changed void-returning trylock functions to return bool in tests. (Probably
needs another pass to minimize the diff and undo some unnecessary changes.)
2. Now enforcing bool/int/pointer returns from trylock-annotated
https://github.com/dmcardle updated
https://github.com/llvm/llvm-project/pull/95290
>From e53ddc9e9ce0ddd8b5dfd5dfd4c8654afe643ce2 Mon Sep 17 00:00:00 2001
From: Dan McArdle
Date: Mon, 17 Jun 2024 17:53:30 -0400
Subject: [PATCH] [clang][ThreadSafety] Enforce trylock function return type
With
dmcardle wrote:
Thanks, @AaronBallman!
I tried strictly enforcing a `bool` return type, but I ran into some
interesting test failures.
* A handful of functions in the parsing tests return `void` and yet are
annotated as trylock functions. I don't believe this is a valid use case. What
does
dmcardle wrote:
@AaronBallman, please take a look!
What do you think of this approach? I suppose it might be even better to
enforce that the function's return type is `bool`, which would align with the
[ThreadSafetyAnalysis
https://github.com/dmcardle ready_for_review
https://github.com/llvm/llvm-project/pull/95290
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dmcardle updated
https://github.com/llvm/llvm-project/pull/95290
>From 9a9bf80b0fc51dd4ef660e2a2fe625af26e85c2a Mon Sep 17 00:00:00 2001
From: Dan McArdle
Date: Wed, 12 Jun 2024 14:57:49 -0400
Subject: [PATCH] [clang][ThreadSafety] Warn when constructor is trylock
With this
https://github.com/dmcardle created
https://github.com/llvm/llvm-project/pull/95290
With this change, Clang will generate a warning when a constructor is annotated
as a trylock function.
Issue #92408
>From f717082e700645f1fa6ca738a540aef20c2ba015 Mon Sep 17 00:00:00 2001
From: Dan McArdle
22 matches
Mail list logo
