Description of problem:
clang's Thread Safety Analysis does not take into account __attribute__((cleanup)). Therefore it misses lock guards and similar patterns where a resource is released in an __attribute__((cleanup)) function.

This appears to affect both C and C++ programs. The use of __attribute__((cleanup)) is somewhat common in QEMU because it is a C program without C++ RAII abilities.

Version-Release number of selected component (if applicable):
clang-15.0.7-2.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. $ cat >a.c
#include <assert.h>
#include <pthread.h>

typedef pthread_mutex_t __attribute__((capability("mutex"))) mutex;

static mutex lock = PTHREAD_MUTEX_INITIALIZER;
static int counter __attribute__((guarded_by(lock)));

void mutex_lock(mutex *m) __attribute__((acquire_capability(lock))) __attribute__((no_thread_safety_analysis))
{
    pthread_mutex_lock(m);
}

void mutex_unlock(mutex *m) __attribute__((release_capability(lock))) __attribute__((no_thread_safety_analysis))
{
    pthread_mutex_unlock(m);
}

struct guard
{
    /* Nothing */
};

static void guard_cleanup(struct guard *unused) __attribute__((release_capability(lock)))
{
    mutex_unlock(&lock);
}

int main(int argc, char **argv)
{
    {
        mutex_lock(&lock);
        struct guard __attribute__((cleanup(guard_cleanup))) guard;

        counter++;
    }

    counter--; /* this should fail */
    return 0;
}
^D
2. clang -Wthread-safety -o a a.c

Actual results:
a.c:40:1: warning: mutex 'lock' is still held at the end of function [-Wthread-safety-analysis]
}
^
a.c:32:9: note: mutex acquired here
        mutex_lock(&lock);
        ^
1 warning generated.

This is wrong. The lock is released in guard_cleanup() before the scope inside main() ends.

Expected results:
A warning should identify that counter-- accesses the field without holding the lock.

Additional info: