为什么互斥引用上的 lock_guard 会产生 C26110答案

【问题标题】：Why does a lock_guard on a mutex reference produce C26110为什么互斥引用上的 lock_guard 会产生 C26110
【发布时间】：2020-03-01 18:04:27
【问题描述】：

Visual Studio Professional 2019 项目（版本 16.3.6）中的以下代码会产生警告：

#include <thread>
#include <future>

class Foo {
public:
    mutable std::recursive_mutex _writingMutex;
    std::recursive_mutex& writingMutex() const { return _writingMutex; }
};

int main()
{
    Foo a;
    std::lock_guard<std::recursive_mutex> lock(a.writingMutex()); // produces C26110
    std::lock_guard<std::recursive_mutex> lock2(a._writingMutex); // no warning
}

第一个锁产生警告C26110：

警告 C26110 调用者在调用函数 'std::lock_guard::~lock_guard' 之前未能持有锁 'lock'

为什么会这样？将互斥体作为参考传递是否不起作用？

【问题讨论】：

不能用最近的视觉工作室重现； godbolt.org/z/LEp57M。请提供带有 Visual Studio 版本的minimal reproducible example
@AlanBirtles 添加了版本（Visual Studio Professional，16.3.6），并且缺少问题。该项目没有预编译的头文件，是通过 File->New -> Project 新创建的。这是否满足最小可重现示例的要求？
会不会是 IntelliJ 的问题？当我激活/WX（将警告视为错误）时，解决方案仍然可以编译，但“错误列表”窗口显示警告并且代码行有绿色下划线
错误码>10000是代码分析错误，不是编译错误。显然，在这种特殊情况下，嵌套锁定会触发误报。向 Microsoft 报告（帮助-> 报告问题...）
@rustyx 和 AlanBirtles：感谢您的关注。我根据您的 cmets 回答了我自己的问题

标签： c++ c++11 visual-c++ c++17 std

【解决方案1】：

根据 Alan 的编译结果和 rustyx 的评论，我会回答我自己的问题：

这很可能是 Visual Studio 中的代码分析错误。看起来 C26110 无法通过引用识别互斥锁。该问题已报告here，我在那里添加了我的最小示例作为评论。该问题在最新版本 16.3.7 中仍然存在

【讨论】：