Issue |
139933
|
Summary |
Thread safety/capability analysis behavioral difference between member and free function
|
Labels |
clang:frontend,
clang:analysis
|
Assignees |
|
Reporter |
AaronBallman
|
The following code emits unexpected diagnostics about the capability expecting to be held or still being held within the `*_permission` functions:
```
#if __has_cpp_attribute(clang::capability)
#define CAPABILITY(Name) [[clang::capability(Name)]]
#define ACQUIRE(Cap) [[clang::acquire_capability(Cap)]]
#define RELEASE(Cap) [[clang::release_capability(Cap)]]
#define REQUIRE(Cap) [[clang::requires_capability(Cap)]]
#else
#define CAPABILITY(Name)
#define ACQUIRE(Cap)
#define RELEASE(Cap)
#define REQUIRE(Cap)
#endif
struct CAPABILITY("special permission") SpecialPerms {
} SpecialPermissions;
ACQUIRE(SpecialPermissions) void give_me_permission() {}
RELEASE(SpecialPermissions) void revoke_my_permission() {}
REQUIRE(SpecialPermissions) void func() {}
void good_call() {
give_me_permission();
func();
revoke_my_permission();
}
```
https://godbolt.org/z/d8Ezhsn88
But with a tweak to using member functions instead, no diagnostics are issued:
```
#if __has_cpp_attribute(clang::capability)
#define CAPABILITY(Name) [[clang::capability(Name)]]
#define ACQUIRE(Cap) [[clang::acquire_capability(Cap)]]
#define RELEASE(Cap) [[clang::release_capability(Cap)]]
#define REQUIRE(Cap) [[clang::requires_capability(Cap)]]
#else
#define CAPABILITY(Name)
#define ACQUIRE(Cap)
#define RELEASE(Cap)
#define REQUIRE(Cap)
#endif
struct CAPABILITY("special permission") SpecialPerms {
ACQUIRE() void give_me_permission() {}
RELEASE() void revoke_my_permission() {}
} SpecialPermissions;
REQUIRE(SpecialPermissions) void func() {}
void good_call() {
SpecialPermissions.give_me_permission();
func();
SpecialPermissions.revoke_my_permission();
}
```
https://godbolt.org/z/Eoh8xKnje
Am I holding it wrong in the free function example or is this an issue with the analysis?
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs