带有 clang-tidy 的现代 c++ 会导致相反的警告

Question

这是我的第二个问题，我试图找到一个匹配的请求，希望这次我没有忽略它。

我试图更深入地了解现代 C++。 所以一个提示是通过使用 clang 自己教它，我正在尝试它 atm 但我被卡住了，因为一个 function 在我尝试使其正确时引起相反的警告。

背景信息：我正在使用 singleton 模式，它需要在源代码的多个位置返回唯一的一个实例。 这是一个简单的实现，我知道多线程程序中可能存在的问题。 但这正在建设中。 检查是通过 VSCode-1-73-1 中的 clang 构建完成的，选项是 --checks=*，这是 Jason Turner 为学习现代 C++ 所推荐的。唯一禁用的检查是 llvmlibc-*，因为它会给命名空间带来很多麻烦。

这是源代码的第一个警告 < use a trailing return type for this function C/C++ (modernize-use-trailing-return-type) >：

namespace some::own::implementations {

  Example* Example::getInstance() { // <-- hint for getInstance
    static Example _instance;
    return &_instance;
  }

} //  namespace some::own::implementations

错误的解释并不难，所以我重构了它（包括我在此处跳过的 header 部分）并得到了下一个提示 < this function declaration C/C++ (fuchsia-trailing-return) > 不允许尾随返回类型>：

namespace some::own::implementations {

  auto Example::getInstance() -> Example* { // <-- hint for auto
    static Example _instance;
    return &_instance;
  }

} //  namespace some::own::implementations

好的，现在我有点困惑怎么了？ 好的，一种解释可能是第一个暗示，使用 modernize-use-trailing-return-type 是更一般的解释，紫红色可能是公司或集团的理念，允许将规则添加到 clang，因为我们可以取消选择它们。

我现在想到的问题：

1. 关于现代化和紫红色的解决方案是否正确？
2. 将相反的警告添加到应该或可以教人们正确实施现代 C++ 代码的工具是否有意义？
3. 如果支票中有不同的哲学（我不知道 atm），那么尝试学习现代 C++ 的人应该遵循哪一个？
4. function 的正确解决方案是什么？

Answer 1

1. 没错，Fuchsia 是一组开发人员的意见，而 lint 检查是 diffe.net 一组开发人员的意见，有时他们是不同的意见。

https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/lint阐明 Fuchsia 禁用了这些检查：

- clang-diagnostic-unused-command-line-argument - ninja-generated compilation database contains the linker argument, which ends up unused and triggers this warning for every file
- misc-noexcept* - Fuchsia doesn't use C++ exceptions
- misc-non-private-member-variables-in-classes - We don't allow classes/structs with a mix of private and public members, but all public is fine.
- modernize-deprecated-headers - Fuchsia uses old-style C headers
- modernize-use-nodiscard - Not generally used in the Fuchsia codebase
- modernize-raw-string-literal - the check was suggesting to convert \xFF literals, which we'd rather keep in the escaped form.
- modernize-return-braced-init-list - concerns about readability of returning braced initialization list for constructor arguments, prefer to use a constructor explicitly
- modernize-use-emplace - enabled the IgnoreImplicitConstructors option to comply with Abseil Tip of the Week #112.
- modernize-use-equals-delete - flagging all gtest TEST_F
- modernize-use-trailing-return-type - Fuchsia C++ code typically uses the int foo() style of defining functions, and not the auto foo() -> int style as recommended by this check.
- readability-implicit-bool-conversion - Fuchsia C++ code commonly uses implicit bool cast of pointers and numbers
- readability-isolate-declaration - Zircon code commonly uses paired declarations.
- readability-uppercase-literal-suffix - Fuchsia C++ code chooses not to impose a style on this.

2. 通常人们启用他们同意的检查。 不希望有人启用所有检查。
3. 确实有不同的哲学。 您应该遵循您最同意的那个。
4. 两者都不对。 他们都是意见。