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 t
@@ -614,9 +619,23 @@ static bool checkTryLockFunAttrCommon(Sema &S, Decl *D,
const ParsedAttr &AL,
return false;
}
- // check that all arguments are lockable objects
+ // Check that all remaining arguments are lockable objects.
checkAttrArgsAreCapabilityObjs(S, D,
@@ -614,9 +619,23 @@ static bool checkTryLockFunAttrCommon(Sema &S, Decl *D,
const ParsedAttr &AL,
return false;
}
- // check that all arguments are lockable objects
+ // Check that all remaining arguments are lockable objects.
checkAttrArgsAreCapabilityObjs(S, D,
@@ -614,9 +619,23 @@ static bool checkTryLockFunAttrCommon(Sema &S, Decl *D,
const ParsedAttr &AL,
return false;
}
- // check that all arguments are lockable objects
+ // Check that all remaining arguments are lockable objects.
checkAttrArgsAreCapabilityObjs(S, D,
@@ -614,9 +619,23 @@ static bool checkTryLockFunAttrCommon(Sema &S, Decl *D,
const ParsedAttr &AL,
return false;
}
- // check that all arguments are lockable objects
+ // Check that all remaining arguments are lockable objects.
checkAttrArgsAreCapabilityObjs(S, D,
AaronBallman wrote:
> * 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 `EXCLUSIVE_TRYLOCK_FUNCTION` mean when it's impossible to return a
> value? I think the solution is to just chan
@@ -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_);
dmcar
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 fun
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 t
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 `
AaronBallman 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
> documentation](https://clang.llvm.org/docs/ThreadSafe
https://github.com/AaronBallman commented:
I can see the logic, but it seems like there's a fair amount of related
checking that perhaps should happen as well. Marking a destructor as try_lock
makes even less sense than marking a constructor, so why not prohibit that as
well? And since the try
https://github.com/AaronBallman 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
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
documentation](https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Dan McArdle (dmcardle)
Changes
With this change, Clang will generate a warning when a constructor is annotated
as a trylock function.
Issue #92408
---
Full diff: https://github.com/llvm/llvm-project/pull/95290.diff
2 Files Affected:
-
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
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be
notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it
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
Da
19 matches
Mail list logo
