Warning to discover unnamed variable

Recently I've met a bug in C++ project related to an unnamed scope guard, like in this question:

LockGuard(mutex);

See simple demo.

This kind of bug is really hard to find by reviwing changes, and also hard to debug. I'd like to use an automatic check in CI.

Is there any compiler (gcc, clang, cl) warning or static analysis tool that may point to the issue?

Newer versions of the C++ standard have an attribute named [[nodiscard]], which can also be applied to constructors.

So if you write a class like the following:

template<typename M>
class my_lock_guard {
public:
    [[nodiscard]] my_lock_guard(M& mutex)
        : m_mutex(mutex)
    {
        m_mutex.lock();
    }

    ~my_lock_guard()
    {
        m_mutex.unlock();
    }

private:
    M& m_mutex;
};

then the following code will produce a compiler warning in new-enough compilers:

static std::mutex my_mutex_var;
static int global_var;
void foo()
{
    my_lock_guard<std::mutex>{my_mutex_var};
    global_var = 42;
}

You can check this out on compiler explorer, where the 3 major compilers will generate a warning for the usage in foo(). (But if you add a variable name there, the warning disappears.)

So for all RAII classes of this type you write yourself (i.e. classes that just exist for being used within the current scope, but are never touched after construction), simply add [[nodiscard]] to all constructors, and that will automatically cause the appropriate compiler warnings.

Unfortunately this attribute was not added to enough parts of the C++ standard library in the currently available standards versions yet. Neither lock_guard, nor scoped_lock, nor unique_lock, nor shared_lock have [[nodiscard]] constructors up to and including C++23. For those classes in the standard library, you have to use other tooling. As was mentioned by other people in the commends, clang-tidy can apparently also find these types of issues, regardless of the presence of the attribute. I would still recommend that your own could should use this attribute in the appropriate cases anyway, because then you'll already see this issue on a compiler level.

(Also note that my_lock_guard above is a minimalistic example, it is not a full replacement of std::lock_guard; don't use my example in production code please.)