NET-3390 Update RSPEC before 10.22 release

GitOrigin-RevId: 8117fedb2e60c617fbc04a80523f55043d4420cf

Author: oleksandr-selehenenko-sonarsource

analyzers/rspec/cs/S1694.html

@@ -42,9 +42,9 @@ <h3>Exceptions</h3>
 }
 </pre>
 <p>Notice that, since C# 8.0, you can also define <a
-href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/default-interface-methods">default implementations for
-interface methods</a>, which is yet another reason to prefer interfaces over abstract classes when you don’t need to provide any inheritable
-behavior.</p>
+href="https://learn.microsoft.com/en-us/dotnet/csharp/advanced-topics/interface-implementation/default-interface-methods-versions">default
+implementations for interface methods</a>, which is yet another reason to prefer interfaces over abstract classes when you don’t need to provide any
+inheritable behavior.</p>
 <p>However, interfaces cannot have fields (such as <code>switchLamp</code> in the example above), and that remains true even in C# 8.0 and upwards.
 This can be a valid reason to still prefer an abstract class over an interface.</p>
 <h2>How to fix it</h2>
@@ -74,9 +74,8 @@ <h3>Documentation</h3>
   and Sealed Classes and Class Members (C# Programming Guide)</a></li>
   <li>Microsoft Learn - <a href="https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/interfaces/">Interfaces - define behavior for
   multiple types</a></li>
-  <li>Microsoft Learn - <a
-  href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/default-interface-methods">Default Interface
-  Methods</a></li>
+  <li>C# Language Design - <a href="https://github.com/dotnet/csharplang/blob/main/proposals/csharp-8.0/default-interface-methods.md">Default
+  Interface Methods</a></li>
   <li>Microsoft Learn - <a
   href="https://learn.microsoft.com/en-us/dotnet/csharp/advanced-topics/interface-implementation/default-interface-methods-versions">Tutorial: Update
   interfaces with default interface methods</a></li>

analyzers/rspec/cs/S2190.html

@@ -43,8 +43,7 @@ <h3>Recursion</h3>
   <li><strong>Stack overflow</strong>: Recursive functions can lead to <a
   href="https://learn.microsoft.com/en-us/dotnet/api/system.stackoverflowexception">stack overflow</a> if the recursion is too deep, potentially
   causing the program to crash.</li>
-  <li><strong>Performance overhead</strong>: Recursive function calls can lead to poor performance due to the need to push and pop <a
-  href="https://en.citizendium.org/wiki/Stack_frame#:~:text=In%20computer%20science%2C%20a%20stack,only%20exist%20at%20run%2Dtime">stack frames</a>,
+  <li><strong>Performance overhead</strong>: Recursive function calls can lead to poor performance due to the need to push and pop stack frames,
   making them potentially slower than iterative solutions.</li>
   <li><strong>Difficulty in debugging</strong>: Debugging recursive code can be challenging, as multiple recursive calls can make it harder to track
   the flow of execution and identify logical errors.</li>

analyzers/rspec/cs/S3267.html

@@ -118,8 +118,8 @@ <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
   <li>Microsoft Learn - <a href="https://learn.microsoft.com/en-us/dotnet/csharp/linq">Language Integrated Query (LINQ)</a></li>
-  <li>Microsoft Learn - <a
-  href="https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.iasyncenumerable-">https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.iasyncenumerable-</a> 1[IAsyncEnumerable&lt;T&gt; Interface]</li>
+  <li>Microsoft Learn - <a href="https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.iasyncenumerable-1">IAsyncEnumerable&lt;T&gt;
+  Interface</a></li>
   <li>Microsoft Learn - <a
   href="https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/10.0/asyncenumerable">System.Linq.AsyncEnumerable in .NET
   10</a></li>

analyzers/rspec/cs/S3416.html

@@ -111,7 +111,7 @@ <h3>Articles &amp; blog posts</h3>
 <ul>
   <li>Raygun Blog - <a href="https://raygun.com/blog/c-sharp-logging-best-practices/">C# logging: Best practices in 2023 with examples and
   tools</a></li>
-  <li>Apache Logging - <a href="https://logging.apache.org/log4net/release/manual/configuration.html">Apache log4net Manual - Configuration</a></li>
+  <li>Apache Logging - <a href="https://logging.apache.org/log4net/manual/configuration.html">Apache log4net Manual - Configuration</a></li>
   <li>GitHub NLog repository - <a href="https://github.com/nlog/nlog/wiki/Tutorial#best-practices-for-using-nlog">Best practices for using
   NLog</a></li>
 </ul>

analyzers/rspec/cs/S8367.html

@@ -1,82 +1,95 @@
 <p>This rule raises an issue when code uses 'field' as an identifier in contexts where it conflicts with the new <code>field</code> contextual keyword
 introduced in C# 14.</p>
 <h2>Why is this an issue?</h2>
-<p>C# 14 introduces the <code>field</code> contextual keyword for field-backed properties. This keyword allows you to access synthesized backing
+<p>C# 14 introduces the <code>field</code> contextual keyword for field-backed properties. This keyword allows access to the synthesized backing
 fields directly within property accessors, simplifying property implementations that need custom logic.</p>
-<p>When your code uses 'field' as an identifier, several problems can occur:</p>
+<p>By using 'field' as an identifier, several problems can occur:</p>
 <ul>
-  <li><strong>Compilation errors</strong>: Local variables or parameters named 'field' within property accessors will cause compiler error CS9272,
-  preventing your code from compiling.</li>
-  <li><strong>Semantic confusion</strong>: Existing class members named 'field' may be overshadowed by the synthesized backing field when referenced
-  within property accessors, leading to unexpected behavior.</li>
-  <li><strong>Upgrade barriers</strong>: Code that compiles in earlier C# versions may break when upgrading to C# 14.</li>
+  <li><strong>Compilation errors</strong>: Local variable declarations or parameters named <code>field</code> within property accessors cause compiler
+  error CS9273. References to existing members named <code>field</code> within property accessors cause compiler error CS9258. See <a
+  href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/property-declaration-errors">Compiler errors on property
+  declarations</a>.</li>
+  <li><strong>Semantic confusion</strong>: Existing class members named <code>field</code> may be unexpectedly overshadowed by the synthesized backing
+  field when referenced within property accessors, leading to logic errors and unexpected runtime behavior.</li>
+  <li><strong>Upgrade barriers</strong>: Code that compiles successfully in C# 13 and earlier may fail to compile or change behavior when upgrading to
+  C# 14.</li>
 </ul>
-<p>The <code>field</code> keyword specifically refers to compiler-synthesized backing fields for properties. When the compiler encounters 'field'
-within a property accessor, it treats it as this special keyword rather than a regular identifier, which can cause conflicts with your existing
-code.</p>
 <h3>What is the potential impact?</h3>
-<p>Using 'field' as an identifier can prevent successful compilation when upgrading to C# 14. In property accessors, local variables named 'field'
-will cause compilation errors, while class members named 'field' may be unexpectedly overshadowed by synthesized backing fields, leading to logic
-errors and unexpected runtime behavior.</p>
+<p>Using 'field' as an identifier can prevent successful compilation when upgrading to C# 14. In property accessors, local variables or parameters
+named 'field' will cause compilation errors, while class members named 'field' may be unexpectedly overshadowed by synthesized backing fields, leading
+to logic errors and unexpected runtime behavior.</p>
 <h2>How to fix it</h2>
-<p>Rename class members that use 'field' as an identifier to avoid conflicts with the contextual keyword, or escape the field identifier with "@".</p>
+<p>Rename the identifier, escape it by prefixing with <code>@</code>, or qualify member access with <code>this.</code> or <code>base.</code> to avoid
+conflicts with the contextual keyword. This rule applies only inside property <code>get</code>, <code>set</code>, and <code>init</code> accessors;
+indexer and event accessors are not affected.</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
 <pre data-diff-id="1" data-diff-type="noncompliant">
-public class MyClass
+public class ClassFieldExample
 {
-    private string field; // Noncompliant
+    private string field;
 
     public string Message
     {
-        get =&gt; field;
-        set =&gt; field = value;
+        get =&gt; field; // Noncompliant
+        set =&gt; field = value; // Noncompliant
     }
 }
-
-public class MyClass2
+</pre>
+<pre data-diff-id="2" data-diff-type="noncompliant">
+public class LocalFunctionExample
 {
-    private string field; // Noncompliant
-
-    public string Message
+    public int Value
     {
-        get =&gt; field;
-        set =&gt; field = value;
+        get
+        {
+            return LocalFunction(42);
+
+            int LocalFunction(int field) // Noncompliant
+                =&gt; field;
+        }
     }
 }
 </pre>
 <h4>Compliant solution</h4>
 <pre data-diff-id="1" data-diff-type="compliant">
-public class MyClass
+public class ClassFieldExample
 {
-    private string _field;
+    private string field;
 
     public string Message
     {
-        get =&gt; _field;
-        set =&gt; _field = value;
+        get =&gt; this.field;          // or @field
+        set =&gt; this.field = value;  // or @field = value;
     }
 }
-
-public class MyClass2
+</pre>
+<pre data-diff-id="2" data-diff-type="compliant">
+public class LocalFunctionExample
 {
-    private string field;
-
-    public string Message
+    public int Value
     {
-        get =&gt; @field;
-        set =&gt; @field = value;
+        get
+        {
+            return LocalFunction(42);
+
+            int LocalFunction(int value) // Compliant - renamed
+                =&gt; value;
+        }
     }
 }
 </pre>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li>What’s new in C# 14 - The field keyword - <a
-  href="https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-14#the-field-keyword">Official Microsoft documentation explaining the field
-  keyword feature in C# 14</a></li>
-  <li>Breaking changes in Roslyn - field keyword conflicts - <a
-  href="https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/breaking-changes/compiler%20breaking%20changes%20-%20dotnet%2010">Documentation of
-  breaking changes related to the field keyword in C# 14</a></li>
+  <li>Microsoft Learn - <a href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/field">The <code>field</code>
+  keyword</a></li>
+  <li>Microsoft Learn - <a
+  href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/property-declaration-errors">Compiler errors on property
+  declarations</a></li>
+  <li>Microsoft Learn - <a
+  href="https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/breaking-changes/compiler%20breaking%20changes%20-%20dotnet%2010#expression-field-in-a-property-accessor-refers-to-synthesized-backing-field">C# compiler breaking changes since C# 13 - Expression <code>field</code> in a property accessor refers to synthesized backing field</a></li>
+  <li>Microsoft Learn - <a
+  href="https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/breaking-changes/compiler%20breaking%20changes%20-%20dotnet%2010#variable-named-field-disallowed-in-a-property-accessor">C# compiler breaking changes since C# 13 - Variable named <code>field</code> disallowed in a property accessor</a> (documentation incorrectly references CS9272; the actual error code is CS9273)</li>
 </ul>
 

analyzers/rspec/cs/S8367.json

@@ -11,14 +11,14 @@
     "compatibility",
     "upgrade"
   ],
-  "defaultSeverity": "Blocker",
+  "defaultSeverity": "Critical",
   "ruleSpecification": "RSPEC-8367",
   "sqKey": "S8367",
   "scope": "All",
   "quickfix": "unknown",
   "code": {
     "impacts": {
-      "MAINTAINABILITY": "BLOCKER"
+      "MAINTAINABILITY": "HIGH"
     },
     "attribute": "CONVENTIONAL"
   }

analyzers/rspec/cs/S8368.html

@@ -1,50 +1,71 @@
-<p>This is an issue when using 'extension' as an identifier (class name, method name, variable name, etc.) in C# 14 or later without the '@' escape
-prefix.</p>
+<p>Identifiers named <code>extension</code> should be renamed or use the <code>@</code> escape prefix to avoid breaking changes in C# 14 or later.</p>
 <h2>Why is this an issue?</h2>
-<p>Starting with C# 14, 'extension' becomes a contextual keyword used for extension containers. When the compiler encounters 'extension' in certain
-contexts, it tries to parse it as this new language feature rather than as a regular identifier.</p>
-<p>This change can cause compilation errors in existing code that uses 'extension' as an identifier. For example, a class named 'extension' will be
-interpreted as an extension container declaration, leading to parsing failures.</p>
-<p>The '@' prefix tells the compiler to treat the word as a regular identifier rather than a keyword, resolving the ambiguity and allowing the code to
-compile correctly.</p>
+<p>Starting with C# 14, <code>extension</code> <a
+href="https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/breaking-changes/compiler%20breaking%20changes%20-%20dotnet%2010#extension-treated-as-a-contextual-keyword">is
+a contextual keyword</a> for declaring extension members and extension containers. This change can cause compilation errors in existing code that uses
+the word <code>extension</code> as an identifier. For example, a class named 'extension' will be interpreted as an extension container declaration,
+leading to parsing failures.</p>
+<p>This rule flags any unescaped <code>extension</code> identifiers used in the following cases:</p>
+<ul>
+  <li>Type declaration names</li>
+  <li>Type parameter names</li>
+  <li>Constructor names</li>
+  <li>Using alias names</li>
+  <li>Return types, property types, and field types (including arrays and pointers)</li>
+</ul>
+<p>Note that method names, parameter names, and local variable names are not affected by this breaking change. For example, <code>void extension() {
+}</code> remains valid in C# 14.</p>
 <h3>What is the potential impact?</h3>
-<p>Code that previously compiled successfully will fail to compile with C# 14 or later. This can break builds and prevent applications from being
-updated to newer language versions.</p>
+<p>Code that currently compiles will fail to compile when the project is upgraded to C# 14.</p>
 <h2>How to fix it</h2>
-<p>Change the identifier name, or add the '@' prefix before 'extension' when using it as a class name, constructor name, or method name.</p>
+<p>Rename the identifier, or add the <code>@</code> prefix to it.</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
 <pre data-diff-id="1" data-diff-type="noncompliant">
-class extension
+class extension { }
+class MyClass
 {
-    extension(object o) { } // Noncompliant
-    extension M() { } // Noncompliant
+    extension field;
+    extension Property { get; }
 }
 </pre>
 <h4>Compliant solution</h4>
+<p>Escape the identifier with the <code>@</code> verbatim prefix:</p>
 <pre data-diff-id="1" data-diff-type="compliant">
-class @extension
+class @extension { }
+class MyClass
 {
-    @extension(object o) { }
-    @extension M() { }
+    @extension field;
+    @extension Property { get; }
 }
 </pre>
-<p>or</p>
-<pre data-diff-id="1" data-diff-type="compliant">
-class MyExtension
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="2" data-diff-type="noncompliant">
+class extension { }
+class MyClass
+{
+    extension ReturnType() { return default; }
+}
+</pre>
+<h4>Compliant solution</h4>
+<p>Rename the identifier:</p>
+<pre data-diff-id="2" data-diff-type="compliant">
+class MyExtension { }
+class MyClass
 {
-    MyExtension(object o) { }
-    MyExtension M() { }
+    MyExtension ReturnType() { return default; }
 }
 </pre>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li>C# Breaking Changes in .NET 10 - <a
-  href="https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/breaking-changes/compiler%20breaking%20changes%20-%20dotnet%2010">Official Microsoft
-  documentation about breaking changes in C# 14, including the 'extension' contextual keyword</a></li>
-  <li>C# Identifiers - <a
-  href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/lexical-structure#643-identifiers">C# language
-  specification section on identifiers and the '@' escape mechanism</a></li>
+  <li>Microsoft Learn - <a
+  href="https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/breaking-changes/compiler%20breaking%20changes%20-%20dotnet%2010#extension-treated-as-a-contextual-keyword"><code>extension</code> treated as a contextual keyword</a></li>
+  <li>Microsoft Learn - <a href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/extension">Extension member
+  declarations</a></li>
+  <li>Microsoft Learn - <a href="https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/extension-members">Explore extension members in
+  C# 14</a></li>
+  <li>Microsoft Learn - <a href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/verbatim">Verbatim identifiers
+  (<code>@</code> prefix)</a></li>
 </ul>
 

analyzers/rspec/cs/S8368.json

@@ -4,7 +4,7 @@
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
-    "constantCost": "5 min"
+    "constantCost": "1 min"
   },
   "tags": [
     "csharp14",