Seems C++17 related rules are sometimes applying to C++14

[magicmalcsiress (Malcolm Davey)]

Make sure to read this post before raising a thread here:

How to Report a False-positive / False-negative

Hey SonarSource Community! False-positives happen, as do false-negatives, and we’re eager to fix them. We are thrilled when our users report problems, so we can make our products better. What is a false-positive (FP)? A false-positive is when an issue is raised unexpectedly on code that should not trigger an issue, or where the suggested action doesn’t make any sense for the code. What is a false-negative (FN)? A false-negative is when an issue should be raised on a piece of code, but isn’t…

Then tell us:

• What language is this for: C++14
• Which rule : cpp:S6020
• Why do you believe it’s a false-positive/false-negative?
• Are you using
  • SonarQube - * Enterprise Edition v10.6 (92116)
• How can we reproduce the problem? Give us a self-contained snippet of code (formatted text, no screenshots)

static_assert(! std::is_reference<UnderlyingT>::value, "....");

This is reporting cpp S6020 error about needing ti use is_reference_v for code that we need to compile as C++14, but is_reference_v is only for C++17

We have some code which we compile as both C++14, but also we compile as C++17, but have ifdef for some cases were we have C++17 specific code in some header files.
(This is a shared library, so in some case down stream apps use C++17 or later, and some use C++14)

This is also applying the label : since-c++14

[aalvarez (Alejandro Álvarez Ayllón)]

Hello,

When a source file is compiled multiple times, the analyzer considers only one of them—always the same (or it should), but only one. In this case, it is likely the C++17 compilation.

You can, nevertheless, force the analyzer to apply a specific standard and override the one used for compilation.

sonar.cfamily.reportingCppStandardOverride=c++14

This should silence issues that apply starting at c++17.

Please, let me know if this helps.