Add rspec

Author: michael-jabbour-sonarsource

rules/S8216/cfamily/metadata.json

@@ -1,24 +1,24 @@
 {
-  "title": "FIXME",
+  "title": "Code should not rely on features beyond the configured C++ standard",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "5min"
   },
   "tags": [
+    "lock-in"
   ],
-  "defaultSeverity": "Major",
+  "defaultSeverity": "Minor",
   "ruleSpecification": "RSPEC-8216",
   "sqKey": "S8216",
   "scope": "All",
-  "defaultQualityProfiles": ["Sonar way"],
-  "quickfix": "unknown",
+  "defaultQualityProfiles": [
+  ],
+  "quickfix": "infeasible",
   "code": {
     "impacts": {
-      "MAINTAINABILITY": "HIGH",
-      "RELIABILITY": "MEDIUM",
-      "SECURITY": "LOW"
+      "MAINTAINABILITY": "LOW"
     },
     "attribute": "CONVENTIONAL"
   }

rules/S8216/cfamily/rule.adoc

@@ -1,44 +1,121 @@
-FIXME: add a description
-
-// If you want to factorize the description uncomment the following line and create the file.
-//include::../description.adoc[]
+Code should not rely on features beyond the configured {cpp} standard
 
 == Why is this an issue?
 
-FIXME: remove the unused optional headers (that are commented out)
+Relying on features that are not part of the configured {cpp} standard leads to non-portable builds and fragile code. Some toolchains accept such code as extensions or for backward compatibility, while others strictly reject it under the same standard setting. This rule flags:
+
+* Uses of features from future {cpp} standards (compared to the configured standard).
+* Uses of features removed in the configured {cpp} standard.
+* Uses of C-only constructs that some {cpp} implementations accept as extensions.
 
-//=== What is the potential impact?
+Keeping code within the configured standard ensures consistency across compilers and prevents accidental lock-in to permissive extensions.
 
 == How to fix it
-//== How to fix it in FRAMEWORK NAME
 
-=== Code examples
+Replace uses of out-of-scope features with standard-conforming alternatives that exist in the configured {cpp} standard. If the newer feature (or a removed feature) is truly required, upgrade (or align) the project’s configured standard and all toolchains consistently.
 
-==== Noncompliant code example
+=== Defaulted comparison operators
 
+Defaulted comparison operators are introduced in {cpp}20. When the configured standard is earlier than {cpp}20, using defaulted comparison operators is noncompliant. Under {cpp}20 or later, the same code is compliant.
+
+==== Noncompliant code example
 [source,cpp,diff-id=1,diff-type=noncompliant]
 ----
-FIXME
+struct Account {
+  int id;
+  bool operator==(const Account&) const = default; // Noncompliant before {cpp}20
+};
 ----
 
 ==== Compliant solution
-
 [source,cpp,diff-id=1,diff-type=compliant]
 ----
-FIXME
+struct Account {
+  int id;
+  bool operator==(const Account& other) const { return id == other.id; }
+};
+----
+
+=== Using enum declaration
+
+The "using enum" declaration is a {cpp}20 feature. When the configured standard is earlier than {cpp}20, it is noncompliant to rely on it. Under {cpp}20 or later, the same code is compliant.
+
+==== Noncompliant code example
+[source,cpp,diff-id=2,diff-type=noncompliant]
+----
+enum class Status { Ok, Error };
+using enum Status; // Noncompliant before {cpp}20
+auto s = Ok;
+----
+
+==== Compliant solution
+[source,cpp,diff-id=2,diff-type=compliant]
+----
+enum class Status { Ok, Error };
+auto s = Status::Ok;
+----
+
+=== Lambda template parameter list
+
+Lambda template parameter lists are available starting in {cpp}20. When the configured standard is earlier than {cpp}20, this usage is noncompliant. Under {cpp}20 or later, the same code is compliant.
+
+==== Noncompliant code example
+[source,cpp,diff-id=3,diff-type=noncompliant]
+----
+auto mapValue = []<typename T>(T t) { return t; }; // Noncompliant before {cpp}20
+----
+
+==== Compliant solution
+[source,cpp,diff-id=3,diff-type=compliant]
+----
+auto mapValue = [](auto t) { return t; };
+----
+
+=== C array designators in {cpp}
+
+Some C-only constructs, such as array designators, may be accepted by {cpp} compilers as extensions, but they are not part of the {cpp} standard and should be avoided in {cpp} code.
+
+==== Noncompliant code example
+[source,cpp,diff-id=4,diff-type=noncompliant]
+----
+int values[3] = { [1] = 5 }; // Noncompliant in {cpp}
+----
+
+==== Compliant solution
+[source,cpp,diff-id=4,diff-type=compliant]
+----
+int values[3] = {};
+values[1] = 5;
+----
+
+=== Removed library feature
+
+Some features are removed in newer standards. For example, ``++std::auto_ptr++`` was removed in {cpp}17; using it when the configured standard has removed it is noncompliant.
+
+==== Noncompliant code example
+[source,cpp,diff-id=5,diff-type=noncompliant]
+----
+#include <memory>
+
+std::auto_ptr<int> p(new int(42)); // Noncompliant in {cpp}17 and later
+----
+
+==== Compliant solution
+[source,cpp,diff-id=5,diff-type=compliant]
+----
+#include <memory>
+
+std::unique_ptr<int> p = std::make_unique<int>(42);
 ----
 
-//=== How does this work?
+=== Limitations
 
-//=== Pitfalls
+This version primarily reports extensions starting from {cpp}20 and later. For example, it does not yet report use of a {cpp}17-only feature when the configured standard is {cpp}14. This limitation is temporary and will be addressed in a future update.
 
-//=== Going the extra mile
+== Resources
 
+=== Related rules
 
-//== Resources
-//=== Documentation
-//=== Articles & blog posts
-//=== Conference presentations
-//=== Standards
-//=== External coding guidelines
-//=== Benchmarks
+* S3715 - GNU extensions should not be used
+* S8230 - MSVC-specific extensions should not be used
+* S8231 - Non-standard attributes should not be used