modern c++ with clang-tidy causes opposite warnings

Question

this is my 2nd question and i tried to find a matching request and hope i didn't overlooked it this time.

I'm trying to understand modern C++ a little bit more in depth. So a hint was teaching it yourself by using clang and i'm trying it atm but i'm stucked because of one function causing opposite warnings when i try to make it right.

Background information: I'm using a singleton pattern which needs to return the only one instance at multiple positions in the source code. This is a simple implementation and i know about possible problems in multi-thread programs. But this is under construction. The checks are done with build in clang from VSCode-1-73-1 option is --checks=* as recommended by Jason Turner for learning modern C++. The only disabled check is llvmlibc-* because it causes to much trouble with namespaces.

Here is the first warning with source code < 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

The interpretation of the error is not hard so i refactored it (including the header part i skipped here) and got the next hint < a trailing return type is disallowed for 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

Ok now i'm a little bit confused whats wrong? Ok one interpretation could be the first hint with modernize-use-trailing-return-type is more general one and fuchsia could be the philosophy of a company or group which was allowed to add the rules to clang and because we can deselect them.

Questions i have in my mind now:

1. Is the solution about modernize and fuchsia right?
2. Makes it sense to add opposite warnings to a tool that should or could teach people the right way to implement modern C++ code?
3. If there are different philosophies in the checks (which i don't know atm) which should someone follow who tries to learn modern C++?
4. Whats the right solution for the function?

Answer 1

1. You're right that Fuchsia is the opinions of a set of developers, and the lint checks are the opinons of a diffe.net set of developers, and sometimes they're different opinions.

https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/lint clarifies that Fuchsia disables these checks:

- 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. Usually people enable the checks they agree with. It is not expected for someone to enable all of the checks.
3. There are indeed different philosophies. You should follow the one you agree with the most.
4. Neither is right. They're both opinions.