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

Reply via email to