Add IOperation to DiagnosticExtensions and clean up overloads

[MattKotsenas]

This is a small, preparatory refactoring change. No behavior differences.

• Add IOperation overload to DiagnosticExtensions to simplify creating diagnostics
• Align overloads to pass null for optional parameters instead of a mix of nulls and empty collections
• Use the most appropriate overload in .CreateDiagnostic() calls to simplify code slightly

[coderabbitai]

📝 Walkthrough

Walkthrough

The pull request introduces modifications across several analyzer classes in the Moq.Analyzers namespace, primarily focusing on streamlining the diagnostic reporting process. Key changes include simplifying the creation of Diagnostic objects by directly using relevant parameters instead of first obtaining their locations. This adjustment enhances the clarity and efficiency of the diagnostic reporting without altering the underlying logic or functionality of the analyzers.

Changes

File Path	Change Summary
src/Moq.Analyzers/CallbackSignatureShouldMatchMockedMethodAnalyzer.cs	Updated diagnostic creation in Analyze and ValidateParameters methods to use ParameterList directly.
src/Moq.Analyzers/Common/DiagnosticExtensions.cs	Adjusted method signatures for CreateDiagnostic, changed additionalLocations to null, added new overloads for IOperation.
src/Moq.Analyzers/ConstructorArgumentsShouldMatchAnalyzer.cs	Removed GetLocation() from diagnostic creation in VerifyDelegateMockAttempt and VerifyInterfaceMockAttempt.
src/Moq.Analyzers/SetExplicitMockBehaviorAnalyzer.cs	Updated diagnostic reporting in AnalyzeNewObject and AnalyzeInvocation methods to use CreateDiagnostic directly.
src/Moq.Analyzers/SetupShouldNotIncludeAsyncResultAnalyzer.cs	Simplified diagnostic creation in Analyze method by using mockedMemberExpression directly.

Possibly related PRs

• Update SDK to get newer version of Source Link #202: The changes in the main PR regarding diagnostic creation in the CallbackSignatureShouldMatchMockedMethodAnalyzer class are related to the updates in the SetupShouldNotIncludeAsyncResultAnalyzer, which also modifies diagnostic creation by simplifying the process of reporting diagnostics.
• Refactor to support RS1038 #216: The refactor to support RS1038 includes changes to the Moq.Analyzers namespace, which may relate to the overall structure and functionality of analyzers, including those modified in the main PR.
• Bug/fix issue 144 #224: The modifications in the SetupShouldNotIncludeAsyncResultAnalyzer class, which involve changes to diagnostic reporting, are similar to the changes made in the main PR, indicating a focus on improving diagnostic clarity.
• Add rule to explicitly pick MockBehavior #226: The introduction of a new rule for explicitly choosing mock behavior aligns with the changes in the main PR that enhance diagnostic clarity and reporting in the analyzers.

Suggested labels

analyzers, documentation, releasable, feature

Suggested reviewers

• rjmurillo

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[qlty-cloud-legacy]

Code Climate has analyzed commit c8c5dee and detected 5 issues on this pull request.

Here's the issue category breakdown:

Category	Count
Duplication	5

View more on Code Climate.

[coderabbitai]

Actionable comments posted: 0

🧹 Outside diff range comments (5)

src/Moq.Analyzers/SetupShouldNotIncludeAsyncResultAnalyzer.cs (2)

Line range hint 23-24: Consider addressing the suppressed maintainability warning.

The suppression message references issue #90 for tracking the refactoring. Consider breaking down the Analyze method into smaller, focused methods to improve maintainability. Here's a suggested structure:

- private static void Analyze(SyntaxNodeAnalysisContext context)
+ private static void Analyze(SyntaxNodeAnalysisContext context)
+ {
+     if (ShouldSkipAnalysis(context))
+         return;
+         
+     var setupInvocation = (InvocationExpressionSyntax)context.Node;
+     var mockedMember = GetMockedMember(context, setupInvocation);
+     if (mockedMember == null)
+         return;
+         
+     if (IsInvalidAsyncSetup(context, mockedMember))
+     {
+         ReportDiagnostic(context, mockedMember);
+     }
+ }
+ 
+ private static bool ShouldSkipAnalysis(SyntaxNodeAnalysisContext context)
+ {
+     var moqAssembly = context.Compilation.ReferencedAssemblyNames
+         .FirstOrDefault(a => a.Name.Equals("Moq", StringComparison.OrdinalIgnoreCase));
+     return moqAssembly != null && moqAssembly.Version >= new Version(4, 16, 0);
+ }

---

Line range hint 25-31: Document why analysis is skipped for Moq 4.16.0+.

The code skips analysis for Moq 4.16.0 or later, but it's not clear why. Consider adding a comment explaining if this issue was fixed in that version or if there's another reason for skipping the analysis.

+ // Skip analysis for Moq 4.16.0 or later as this issue was fixed in that version
+ // See: [link to relevant Moq issue/PR]
 if (moqAssembly != null && moqAssembly.Version >= new Version(4, 16, 0))
 {
     return;
 }

src/Moq.Analyzers/CallbackSignatureShouldMatchMockedMethodAnalyzer.cs (1)

Line range hint 54-56: Add null check for setupInvocation

The code dereferences setupInvocation without checking if it's null, which could cause a NullReferenceException.

Apply this fix:

- InvocationExpressionSyntax? mockedMethodInvocation = setupInvocation.FindMockedMethodInvocationFromSetupMethod();
+ if (setupInvocation == null) return;
+ InvocationExpressionSyntax? mockedMethodInvocation = setupInvocation.FindMockedMethodInvocationFromSetupMethod();

src/Moq.Analyzers/ConstructorArgumentsShouldMatchAnalyzer.cs (2)

Line range hint 160-164: Consider enhancing the diagnostic message format.

While the refactoring to simplify diagnostic creation is good, the diagnostic message could be more specific about the provided arguments to help developers quickly identify the issue.

Consider formatting the arguments list for better readability in the diagnostic message:

-        Diagnostic? diagnostic = argumentList?.CreateDiagnostic(InterfaceMustNotHaveConstructorParameters, argumentList);
+        string formattedArgs = string.Join(", ", arguments.Select(arg => arg.ToString()));
+        Diagnostic? diagnostic = argumentList?.CreateDiagnostic(InterfaceMustNotHaveConstructorParameters, formattedArgs);

---

Line range hint 335-341: Fix bug in optional parameters check.

There's a logical issue in the constructor matching condition that could cause false negatives when matching constructors with all optional parameters. The current condition can never be true due to contradictory requirements.

Apply this fix to correctly handle constructors with all optional parameters:

-            if (arguments.Length <= requiredParameters
-                && arguments.Length == 0
-                && requiredParameters == 0
-                && fixedParametersCount != 0)
+            if (arguments.Length == 0 && requiredParameters == 0)

This simplified condition correctly handles the case where:

1. No arguments are provided (arguments.Length == 0)
2. All parameters are optional (requiredParameters == 0)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE

📥 Commits

Files that changed from the base of the PR and between 335ad84 and c8c5dee.

📒 Files selected for processing (5)

• src/Moq.Analyzers/CallbackSignatureShouldMatchMockedMethodAnalyzer.cs (2 hunks)
• src/Moq.Analyzers/Common/DiagnosticExtensions.cs (3 hunks)
• src/Moq.Analyzers/ConstructorArgumentsShouldMatchAnalyzer.cs (2 hunks)
• src/Moq.Analyzers/SetExplicitMockBehaviorAnalyzer.cs (2 hunks)
• src/Moq.Analyzers/SetupShouldNotIncludeAsyncResultAnalyzer.cs (1 hunks)

🧰 Additional context used

📓 Path-based instructions (5)

src/Moq.Analyzers/CallbackSignatureShouldMatchMockedMethodAnalyzer.cs (1)

Pattern **/*.cs: I need your help tracking down and fixing some bugs that have been reported in this codebase.

I suspect the bugs are related to:

• Incorrect handling of edge cases
• Off-by-one errors in loops or array indexing
• Unexpected data types
• Uncaught exceptions
• Concurrency issues
• Improper configuration settings

To diagnose:

1. Review the code carefully and systematically
2. Trace the relevant code paths
3. Consider boundary conditions and potential error states
4. Look for antipatterns that tend to cause bugs
5. Run the code mentally with example inputs
6. Think about interactions between components

When you find potential bugs, for each one provide:

1. File path and line number(s)
2. Description of the issue and why it's a bug
3. Example input that would trigger the bug
4. Suggestions for how to fix it

After analysis, please update the code with your proposed fixes. Try to match the existing code style. Add regression tests if possible to prevent the bugs from recurring.

I appreciate your diligence and attention to detail! Let me know if you need any clarification on the intended behavior of the code.

src/Moq.Analyzers/Common/DiagnosticExtensions.cs (1)

Pattern **/*.cs: I need your help tracking down and fixing some bugs that have been reported in this codebase.

I suspect the bugs are related to:

• Incorrect handling of edge cases
• Off-by-one errors in loops or array indexing
• Unexpected data types
• Uncaught exceptions
• Concurrency issues
• Improper configuration settings

To diagnose:

1. Review the code carefully and systematically
2. Trace the relevant code paths
3. Consider boundary conditions and potential error states
4. Look for antipatterns that tend to cause bugs
5. Run the code mentally with example inputs
6. Think about interactions between components

When you find potential bugs, for each one provide:

1. File path and line number(s)
2. Description of the issue and why it's a bug
3. Example input that would trigger the bug
4. Suggestions for how to fix it

After analysis, please update the code with your proposed fixes. Try to match the existing code style. Add regression tests if possible to prevent the bugs from recurring.

I appreciate your diligence and attention to detail! Let me know if you need any clarification on the intended behavior of the code.

src/Moq.Analyzers/ConstructorArgumentsShouldMatchAnalyzer.cs (1)

Pattern **/*.cs: I need your help tracking down and fixing some bugs that have been reported in this codebase.

I suspect the bugs are related to:

• Incorrect handling of edge cases
• Off-by-one errors in loops or array indexing
• Unexpected data types
• Uncaught exceptions
• Concurrency issues
• Improper configuration settings

To diagnose:

1. Review the code carefully and systematically
2. Trace the relevant code paths
3. Consider boundary conditions and potential error states
4. Look for antipatterns that tend to cause bugs
5. Run the code mentally with example inputs
6. Think about interactions between components

When you find potential bugs, for each one provide:

1. File path and line number(s)
2. Description of the issue and why it's a bug
3. Example input that would trigger the bug
4. Suggestions for how to fix it

After analysis, please update the code with your proposed fixes. Try to match the existing code style. Add regression tests if possible to prevent the bugs from recurring.

I appreciate your diligence and attention to detail! Let me know if you need any clarification on the intended behavior of the code.

src/Moq.Analyzers/SetExplicitMockBehaviorAnalyzer.cs (1)

Pattern **/*.cs: I need your help tracking down and fixing some bugs that have been reported in this codebase.

I suspect the bugs are related to:

• Incorrect handling of edge cases
• Off-by-one errors in loops or array indexing
• Unexpected data types
• Uncaught exceptions
• Concurrency issues
• Improper configuration settings

To diagnose:

1. Review the code carefully and systematically
2. Trace the relevant code paths
3. Consider boundary conditions and potential error states
4. Look for antipatterns that tend to cause bugs
5. Run the code mentally with example inputs
6. Think about interactions between components

When you find potential bugs, for each one provide:

1. File path and line number(s)
2. Description of the issue and why it's a bug
3. Example input that would trigger the bug
4. Suggestions for how to fix it

After analysis, please update the code with your proposed fixes. Try to match the existing code style. Add regression tests if possible to prevent the bugs from recurring.

I appreciate your diligence and attention to detail! Let me know if you need any clarification on the intended behavior of the code.

src/Moq.Analyzers/SetupShouldNotIncludeAsyncResultAnalyzer.cs (1)

Pattern **/*.cs: I need your help tracking down and fixing some bugs that have been reported in this codebase.

I suspect the bugs are related to:

• Incorrect handling of edge cases
• Off-by-one errors in loops or array indexing
• Unexpected data types
• Uncaught exceptions
• Concurrency issues
• Improper configuration settings

To diagnose:

1. Review the code carefully and systematically
2. Trace the relevant code paths
3. Consider boundary conditions and potential error states
4. Look for antipatterns that tend to cause bugs
5. Run the code mentally with example inputs
6. Think about interactions between components

When you find potential bugs, for each one provide:

1. File path and line number(s)
2. Description of the issue and why it's a bug
3. Example input that would trigger the bug
4. Suggestions for how to fix it

After analysis, please update the code with your proposed fixes. Try to match the existing code style. Add regression tests if possible to prevent the bugs from recurring.

I appreciate your diligence and attention to detail! Let me know if you need any clarification on the intended behavior of the code.

🔇 Additional comments (12)

src/Moq.Analyzers/Common/DiagnosticExtensions.cs (3)

8-8: LGTM! Changes to SyntaxNode overloads are well-structured.

The standardization of using null instead of empty collections simplifies the code while maintaining the same behavior. The method chaining is correct and preserves the diagnostic creation hierarchy.

Also applies to: 14-14, 21-27

---

32-32: LGTM! Location overloads maintain proper fallback behavior.

The changes consistently use null for optional parameters while preserving the important fallback to Location.None for non-source locations.

Also applies to: 38-38, 52-52

---

55-71: 🛠️ Refactor suggestion

Consider adding null checks and documentation for IOperation overloads.

While the implementation follows the established pattern, there are a few potential improvements:

1. The code should handle cases where operation or operation.Syntax is null
2. The relationship between IOperation and its underlying Syntax should be documented

Consider applying these changes:

 public static Diagnostic CreateDiagnostic(
     this IOperation operation,
     DiagnosticDescriptor rule,
     IEnumerable<Location>? additionalLocations,
     ImmutableDictionary<string, string?>? properties,
-    params object?[]? messageArgs) => operation.Syntax.CreateDiagnostic(rule, additionalLocations, properties, messageArgs);
+    params object?[]? messageArgs)
+{
+    if (operation is null)
+        throw new ArgumentNullException(nameof(operation));
+        
+    // Fall back to Location.None if we can't get valid syntax
+    var syntax = operation.Syntax ?? throw new ArgumentException("Operation must have associated syntax", nameof(operation));
+    return syntax.CreateDiagnostic(rule, additionalLocations, properties, messageArgs);
+}

And add XML documentation:

/// <summary>
/// Creates a diagnostic from an IOperation instance.
/// </summary>
/// <remarks>
/// This method uses the underlying syntax node of the operation to create the diagnostic.
/// This ensures that the diagnostic is reported at the correct source location.
/// </remarks>
/// <exception cref="ArgumentNullException">Thrown when operation is null.</exception>
/// <exception cref="ArgumentException">Thrown when operation has no associated syntax.</exception>

src/Moq.Analyzers/SetupShouldNotIncludeAsyncResultAnalyzer.cs (1)

66-66: LGTM! Simplified diagnostic creation.

The change aligns with the PR objectives by simplifying the diagnostic creation process while maintaining the same behavior.

src/Moq.Analyzers/SetExplicitMockBehaviorAnalyzer.cs (5)

101-101: LGTM: Simplified diagnostic creation.

The change to use CreateDiagnostic directly on the operation is correct and aligns with the PR objectives of simplifying diagnostic creation.

---

129-129: LGTM: Simplified diagnostic creation.

The change to use CreateDiagnostic directly on the operation is correct and aligns with the PR objectives of simplifying diagnostic creation.

---

Line range hint 25-31: Verify thread safety of compilation analysis registration.

The analyzer correctly enables concurrent execution with EnableConcurrentExecution(). However, we should verify that the compilation analysis registration is thread-safe, particularly around the caching of mock types and behavior symbols.

Let's check for any shared state or potential race conditions:

✅ Verification successful

Let me try a different approach to verify thread safety by looking at the analyzer's implementation more comprehensively.

---

Based on the analyzer's implementation, I can now provide a final response about the thread safety concern:

The analyzer implementation is thread-safe

The implementation shows good thread-safety practices:

• All fields are static and readonly (Title, Message, Rule, SupportedDiagnostics)
• No shared mutable state exists in the analyzer class
• Compilation-specific symbols (mockTypes, mockBehaviorSymbol, ofMethods) are scoped to each compilation analysis context
• Analysis operations are stateless and work only with the data passed through their parameters

The caching of mock types and behavior symbols is handled safely within the scope of each compilation analysis context, with no shared state between different analysis operations.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Look for field declarations that might indicate shared state
ast-grep --pattern 'class SetExplicitMockBehaviorAnalyzer {
  $$$
  private $_* $_* = $_*;
  $$$
}'

Length of output: 101

---

Script:

#!/bin/bash
# Look for the full analyzer class implementation to check field declarations and analysis registration
rg -U "class SetExplicitMockBehaviorAnalyzer" -A 100 --type cs

Length of output: 14882

---

Line range hint 71-99: Consider handling null argument values in mock behavior detection.

The argument analysis in AnalyzeNewObject assumes non-null values when checking for field references. While the current implementation works for standard cases, it might not handle edge cases where argument values are null.

Let's check if there are any tests covering null argument scenarios:

Consider adding null checks:

foreach (IArgumentOperation argument in creationOperation.Arguments)
{
+    if (argument?.Value == null) continue;
     if (argument.Value is IFieldReferenceOperation fieldReferenceOperation)
     {
+        if (fieldReferenceOperation.Member == null) continue;
         ISymbol field = fieldReferenceOperation.Member;
         if (field.ContainingType.IsInstanceOf(mockBehaviorSymbol) && IsExplicitBehavior(field.Name))
         {
             return;
         }
     }
}

---

Line range hint 138-140: Consider using StringComparison.OrdinalIgnoreCase for behavior names.

The IsExplicitBehavior method currently uses case-sensitive comparison. While the current implementation works with the standard Moq API, it might miss custom-defined behaviors or different casing variations.

Let's verify if there are any custom behavior definitions in the codebase:

Consider updating to:

private static bool IsExplicitBehavior(string symbolName)
{
-    return string.Equals(symbolName, "Loose", StringComparison.Ordinal) || string.Equals(symbolName, "Strict", StringComparison.Ordinal);
+    return string.Equals(symbolName, "Loose", StringComparison.OrdinalIgnoreCase) || string.Equals(symbolName, "Strict", StringComparison.OrdinalIgnoreCase);
}

src/Moq.Analyzers/CallbackSignatureShouldMatchMockedMethodAnalyzer.cs (2)

61-62: LGTM: Diagnostic creation simplification

The changes simplify diagnostic creation by using the extension method directly on syntax nodes instead of first getting their locations. This maintains the same functionality while making the code more concise.

Also applies to: 99-100

---

Line range hint 104-134: Verify handling of generic type parameters and user-defined conversions

The type conversion logic handles basic scenarios well, but there might be edge cases with generic type parameters or user-defined conversion operators that could cause false positives/negatives.

Let's verify the handling of these cases:

✅ Verification successful

Let me gather more specific information about the test cases and implementations.

---

Let me gather one final piece of information about the CustomType implementation in the tests.

---

Based on the gathered evidence, I can now provide the final response:

Type conversion handling is properly implemented and tested

The implementation correctly handles all important conversion scenarios:

• The test suite includes comprehensive cases for generic type parameters (e.g., List<string>)
• User-defined conversions are properly tested with CustomType that includes both implicit (int to CustomType) and explicit (string to CustomType) operators
• The analyzer correctly handles nullable types (verified by test case with object?)
• The test cases confirm proper handling of:
  • Identity conversions (same types)
  • Implicit conversions (including user-defined ones)
  • Explicit conversions
  • Generic type parameters

The original concern about potential edge cases with generic type parameters and user-defined conversions is unfounded, as the test suite demonstrates robust handling of these scenarios.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for test cases involving generic parameters and user-defined conversions
rg -l "It\.IsAny<" .
ast-grep --pattern 'class $_ { 
  $$$
  static explicit operator $_($_ $_) {
    $$$
  }
  $$$
}'

Length of output: 380

---

Script:

#!/bin/bash
# Check test cases in CallbackSignatureShouldMatchMockedMethodCodeFixTests.cs
rg -A 10 "It\.IsAny<" ./tests/Moq.Analyzers.Test/CallbackSignatureShouldMatchMockedMethodCodeFixTests.cs

# Look for test cases specifically testing conversion scenarios
rg -A 10 "Conversion|Convert" ./tests/Moq.Analyzers.Test/CallbackSignatureShouldMatchMockedMethodCodeFixTests.cs

# Check for generic type parameter handling in the analyzer
ast-grep --pattern 'class CallbackSignatureShouldMatchMockedMethodAnalyzer {
  $$$
  private static bool HasConversion($_) {
    $$$
  }
}'

Length of output: 7685

---

Script:

#!/bin/bash
# Look for CustomType implementation in test files
rg -A 15 "class CustomType" ./tests/Moq.Analyzers.Test/CallbackSignatureShouldMatchMockedMethodCodeFixTests.cs

Length of output: 594

src/Moq.Analyzers/ConstructorArgumentsShouldMatchAnalyzer.cs (1)

Line range hint 142-146: LGTM! Verify extension method implementation.

The simplified diagnostic creation maintains the same functionality while reducing code complexity. The change is safe as it preserves null handling through the null-conditional operator.

Let's verify the extension method implementation:

✅ Verification successful

Let's try a different search strategy to locate the extension method implementation.

---

LGTM! The extension method implementation is safe and correct.

The search results show that CreateDiagnostic is properly implemented in src/Moq.Analyzers/Common/DiagnosticExtensions.cs. The extension method:

• Correctly handles location tracking by calling GetLocation() internally
• Provides multiple overloads to handle different input types (SyntaxNode, Location, IOperation)
• Maintains proper null safety through optional parameters
• Preserves all diagnostic information including additional locations and properties

The refactoring in ConstructorArgumentsShouldMatchAnalyzer.cs is using this well-implemented extension method, which makes the code more concise while maintaining the same functionality.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the CreateDiagnostic extension method implementation
# to ensure it properly handles location tracking internally

# Search for the CreateDiagnostic extension method definition
ast-grep --pattern 'public static $_ CreateDiagnostic($_) {
  $$$
}'

Length of output: 70

---

Script:

#!/bin/bash
# Search for files containing "CreateDiagnostic" method
rg -l "CreateDiagnostic"

# Then search for the actual implementation with context
rg "CreateDiagnostic" -A 5 -B 2

Length of output: 15629