Add Roslyn Analyzers for String/Span/Char Overloads in Lucene.NET

[NehanPathan]

---

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Currently, calls to StartsWith(), EndsWith(), IndexOf(), and LastIndexOf() on string, Span<char>, ReadOnlySpan<char>, Memory<char>, and ReadOnlyMemory<char> may be made without explicitly specifying StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase. This can lead to subtle bugs due to culture-sensitive comparisons. Additionally, single-character string arguments are sometimes used instead of char overloads, which is less efficient. The project also has custom types like J2N.Text.StringBuilderExtensions, OpenStringBuilder, and ValueStringBuilder that require similar enforcement.

Describe the solution you'd like

Create new Roslyn analyzers for Lucene.NET that enforce the following rules:

1. String overloads must be called with StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase. Violations should emit a compiler error.
2. Span overloads should only be called with StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase when applicable. Violations should emit a compiler warning.
3. Single-character strings should use the char overload of StartsWith/EndsWith/IndexOf/LastIndexOf. Violations should emit an informational diagnostic.
4. The rules should also apply to custom types: J2N.Text.StringBuilderExtensions, OpenStringBuilder, and ValueStringBuilder.

Each analyzer should include:

• Unit tests covering all edge cases
• Sample usage in Lucene.Net.CodeAnalysis.Sample for IDE/live testing
• Proper diagnostic ID assignment in DiagnosticCategoryAndIdRanges.txt
• Corresponding entries in AnalyzerReleases.Unshipped.md

Code fixes:
Where applicable, implement Roslyn code fix providers so the IDE (VS/VS Code) can automatically suggest fixes (lightbulb) when violations are detected.

Alternative solutions considered:

• Existing analyzers (SonarCloud, Microsoft) are insufficient as they do not handle all custom types or escaped characters in single-character strings.

Additional context

This task aligns with Lucene.NET’s goal to enforce safe, consistent, and performant API usage while following .NET best practices. Proper analyzers and code fixes will help contributors avoid subtle bugs and improve code quality.

---

[paulirwin]

Thanks for filing this issue. Are we able to add code fixes for any/all of these analyzers as well? If so let's add that to the description.

[NightOwl888]

Thanks for submitting this issue.

However, it is not clear what is meant by "string overloads" or "span overloads" in the description. The rule to use (LuceneDev6001 vs LuceneDev6002) has nothing to do with the type of parameter being passed to the method. The rule depends on the type that the method is called upon.

• On System.String, the overloads without a StringComparison argument default to StringComparison.CurrentCulture.
• On System.Span<char> the overloads without a StringComparison argument default to StringComparison.Ordinal.
• On System.ReadOnlySpan<char> the overloads without a StringComparison argument default to StringComparison.Ordinal.

"String Overloads"

Therefore, the LuceneDev6001 rule should only apply to all overloads of:

• System.String.IndexOf()
• System.String.LastIndexOf()
• System.String.StartsWith()
• System.String.EndsWith()
• J2N.StringBuilderExtensions.IndexOf()
• J2N.StringBuilderExtensions.LastIndexOf()

See the upstream code at: https://github.com/dotnet/runtime/blob/v9.0.10/src/libraries/System.Private.CoreLib/src/System/String.Searching.cs#L228 to ensure we cover every case (including those that accept a startIndex parameter).

In all of these cases the StringComparison overload must be called and other cases should emit a compiler error with a code fix suggesting to call it with StringComparison.Ordinal.

"Span Overloads"

All of the other usage (including the J2N.Text.OpenStringBuilder and Lucene.Net.Text.ValueStringBuilder types) will be calling the Span/ReadOnlySpan extension methods under the hood, so they must use rule LuceneDev6002, instead.

Additional Rules

Further, we are skipping some of the nuance by limiting to only 3 rules.

Suggest calling without a StringComparison argument on spans to improve performance

On the Span<char> and ReadOnlySpan<char>, J2N.Text.OpenStringBuilder, and Lucene.Net.Text.ValueStringBuilder the overload that accepts a StringComparison.Ordinal value simply cascades the call to the overload that doesn't accept StringComparison. So, if the StringComparson value is Ordinal, we should recommend to remove the StringComparison argument. Do note that this rule should not apply if the StringComparison value is not Ordinal or if calling the method on a System.String.

ReadOnlySpan<char>.IndexOf("foo", StringComparison.Ordinal) -> ReadOnlySpan<char>.IndexOf("foo") // Warning/code fix
ReadOnlySpan<char>.IndexOf("foo", StringComparison.OrdinalIgnoreCase) // Ignore
ReadOnlySpan<char>.IndexOf("foo", StringComparison.CurrentCulture) // Error - we should only ever use Ordinal and OrdinalIgonreCase

String.IndexOf("foo", StringComparison.Ordinal) // Ignore
String.IndexOf("foo", StringComparison.OrdinalIgnoreCase) // Ignore
String.IndexOf("foo") -> String.IndexOf("foo", StringComparson.Ordinal) // Error/code fix
String.IndexOf("foo", StringComparison.InvariantCultureIgnoreCase) // Error - we should only ever use Ordinal and OrdinalIgonreCase

Suggest calling char overload on single character strings that are escaped

There are already Microsoft diagnostic ids to catch when to optimize StartsWith(), EndsWith(), IndexOf() and LastIndexOf() to use the char overload.

https://github.com/dotnet/roslyn-analyzers/pull/6799/files

I think SonarCloud may have similar rules, as well.

The problem is that these rules seem to exclude cases when there are escape characters within the string. For example, if the string is "\"" or "\x0020", there is technically only 1 character in it, but the analyzer doesn't suggest to use the char overload, so we need a custom analyzer and code fix to cover this case. It should work for any string escape sequence that resolves to a single char.

ReadOnlySpan<char>.IndexOf("\"", StringComparison.Ordinal) -> ReadOnlySpan<char>.IndexOf('\"') // Warning/code fix
String.IndexOf("\"", StringComparison.Ordinal) -> String.IndexOf('\"') // Warning/code fix

Furthermore, I think we should use a warning in these cases.

So, we should also elevate these to emit a warning in our .editorconfig file (in this repo).

CA1865 | Performance | Info | UseStringMethodCharOverloadWithSingleCharacters, Documentation
CA1866 | Performance | Info | UseStringMethodCharOverloadWithSingleCharacters, Documentation
CA1867 | Performance | Disabled | UseStringMethodCharOverloadWithSingleCharacters, Documentation

NOTE: Use a plain text editor when working with .editorconfig, not the designer in Visual Studio. The latter may rewrite the whole .editorconfig file format.