.NET 8 developers can verify more APIs for correct usage to speed up their development

[buyaa-n]

With the Roslyn Analyzers we built in .NET 5, 6 and 7, we've found that developers benefit from analyzers that verify correct usage of .NET Libraries APIs. We plan to put more effort on adding valuable analyzers in .NET 8, we will continue working with the community to foster contributions into our collection of analyzers and code fixers.

Community contributors: If you'd like to work on one of the issues marked as "up for grabs", please add a comment directly on that issue asking to get it assigned to you. Please check the getting started guide for reference about how to start and what's need to be done.

Analyzers Planned for .NET 8

Approved analyzers

No	Status	Issue	Estimate
1	✔️ by @CollinAlpert	Prefer Dictionary<K, V>.TryAddValue(key) over guarded Add(key)	Medium
2	✔️ by @CollinAlpert	Prefer .Length/Count/IsEmpty over Any()	Medium
3	✔️ by @fowl2	Do not use OfType() with impossible types	Small
4	✔️ by @steveberdy	Extract array of const to static readonly field	Medium
5	in PR by @psxvoid	Constructor parameters should match property names	Medium
6	in PR by @NewellClark	Prevent wrong usage of string Split	Medium
7	in PR by @NewellClark	Prefer static ReadOnlySpan properties over static readonly byte[] fields	Medium
8	in PR by @NewellClark	Do not pass Utf8JsonReader by value	Medium
9	✔️ @geeknoid	Recommend use of concrete types to maximize devirtualization potential	Medium
10	✔️ @stephentoub	Convert argument null checks to ArgumentNullException.ThrowIfNull	Medium
11	✔️ @Youssef1313	Using StartsWith instead of IndexOf == 0	Medium
12	@NewellClark	Avoid implicitly allocating params arrays in loops	Medium
13	✔️ @carlossanlop	Recommend string.ToLower{Invariant}().Contains/IndexOf/StartsWith("lowercasestring") be replaced by case-insensitive comparison	Medium
14	up for grabs	Usage of ToString in logging source generator method call sites	Medium
15	✔️ @carlossanlop	string.ToLower() == otherString.ToLower()	Small
16	✔️ @mrahhal	Recommend string.StartsWith('c') instead of string.StartsWith("c")	Medium
17	up for grabs	Replacing direct LoggerExtensions.Log* usage with source-generated logging methods	Medium
18	up for grabs	Prefer ValueTuple over Tuple	Medium
19	✔️ @mpidash	Report inefficient use of sets	Small
20	up for grabs	Introduce an analyzer to recommend the more efficient string splitting features in .NET 8	Medium
21	partially implemented @stephentoub	Recommend upgrading to CompositeFormat for enhanced performance	Large
22	up for grabs	Prefer Dictionary.Remove(key, out value) over Dictionary.this[key], followed by Dictionary.Remove(key)	Medium
23	up for grabs	Hide Thread.VolatileRead and Thread.VolatileWrite	Medium
24	in PR by @mpidash	Simplify calls to string.Substring and Memory/Span.Slice	Small
25	@mpidash	Detect the problem of using a System.Type overload instead of the generic overload	Medium
26	up for grabs	Treat calls to ROS op_Equality as warning	Small
27	up for grabs	Detect non-cancelable Task.Delay passed to Task.WhenAny	Medium
28	@tannergooding	Upgrade from platform specific to cross platform intrinsics	Small
29	@tannergooding	Suggest more optimal SIMD patterns where applicable	Medium
30	up for grabs	Adjust/simplify code for numeric IntPtr	Medium
31	up for grabs	Analyzer/fixer for converting Stream.Read calls to ReadAtLeast and ReadExactly	Medium
32	up for grabs	Exceptions thrown inside async methods should be wrapped by Task.FromException	Medium
33	@CollinAlpert	Make types declared in an executable internal	Small
34	up for grabs	Unawaited / returned tasks created with a disposable in using block for that disposable	Large
35	@pedrodeandrade	Async methods that don't take a CancellationToken	Small
36	up for grabs	Use IndexOfAnyValues instead of inlined or cached array	Small
37	✔️ @jozkee	Add an analyzer that warns on single-use JsonSerializerOptions instances

Other analyzer proposals that need to be prepared for API review

1. Add [CallerMustBeUnsafe] attribute to denote APIs which should be called in an unsafe block #31354
2. Warn about ArrayPool.Return without clearArray specified when T is not a value type or has references #71698
3. Roslyn analyzer/fixer: Simplify invocations that receive a start/offset and a count/length #35981
4. Analyzer proposal: EventSource log argument guarding #45215
5. NonCopyable structs attribute and analyzer #50389
6. Analyzer: Validate literal arguments to StringSyntaxAttribute parameters/members #64009
7. Add analyzer for StringBuilder[int] indexer #64545
8. [Analyzer]: Regex analyzers #68962
9. Warnings for in/readonly ref #77625
10. [Analyzer] Lift arrays of literals to static fields #78398

CC @stephentoub @jeffhandley @ericstj @carlossanlop

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

With the Roslyn Analyzers we built in .NET 5, 6 and 7, we've found that developers benefit from analyzers that verify correct usage of .NET Libraries APIs. We plan to put more effort on adding valuable analyzers in .NET 8, we will continue working with the community to foster contributions into our collection of analyzers and code fixers.

Community contributors: If you'd like to work on one of the issues marked as "up for grabs", please add a comment directly on that issue asking to get it assigned to you. Please check the getting started guide for reference about how to start and what's need to be done.

Analyzers Planned for .NET 8

Approved analyzers

Status	Issue	Estimate
in PR by @CollinAlpert	Prefer Dictionary<K, V>.TryAddValue(key) over guarded Add(key)	Medium
up for grabs	Hide Thread.VolatileRead and Thread.VolatileWrite	Medium
in PR by @fowl2	Do not use OfType() with impossible types	Small
in PR by @steveberdy	Extract array of const to static readonly field	Medium
in PR by @psxvoid	Constructor parameters should match property names	Medium
in PR by @NewellClark	Prevent wrong usage of string Split	Medium
up for grabs	Prefer Dictionary.Remove(key, out value) over Dictionary.this[key], followed by Dictionary.Remove(key)	Medium
@NewellClark	Avoid implicitly allocating params arrays in loops	Medium
in PR by @NewellClark	Prefer static ReadOnlySpan properties over static readonly byte[] fields	Medium
in PR by @NewellClark	Do not pass Utf8JsonReader by value	Medium
up for grabs	Convert argument null checks to ArgumentNullException.ThrowIfNull	Medium
up for grabs	Simplify calls to string.Substring and Memory/Span.Slice	Small
up for grabs	Do not discard results of methods that shouldn't be ignored	Large
up for grabs	Detect the problem of using a System.Type overload instead of the generic overload	Medium
up for grabs	Treat calls to ROS op_Equality as warning	Small
up for grabs	Detect non-cancelable Task.Delay passed to Task.WhenAny	Medium

Analyzer proposals planned for .NET 8 that ready API review

• [Analyzer] Adjust/simplify code for numeric IntPtr #74518
• [Analyzer] Recommend string.StartsWith(c) instead of string.StartsWith("c") #78392

Other analyzer proposals planned for .NET 8 that needs to be prepared for API review

1. Add [CallerMustBeUnsafe] attribute to denote APIs which should be called in an unsafe block #31354
2. Analyzer proposal: EventSource log argument guarding #45215
3. NonCopyable structs attribute and analyzer #50389
4. Analyzer: Validate literal arguments to StringSyntaxAttribute parameters/members #64009
5. Add analyzer for StringBuilder[int] indexer #64545
6. Add an analyzer that warns on single-use JsonSerializerOptions instances #65396
7. [Analyzer]: Regex analyzers #68962
8. [Analyzer Proposal]: Analyzer/fixer for converting Stream.Read calls to ReadAtLeast and ReadExactly #69159
9. [Analyzer/fixer suggestion]: Exceptions thrown inside async methods should be wrapped by Task.FromException #70905
10. Warnings for in/readonly ref #77625

CC @stephentoub @jeffhandley @ericstj

Author:	buyaa-n
Assignees:	-
Labels:	area-Meta, User Story
Milestone:	8.0.0

[aradalvand]

The .Any() => .Length != 0 warning makes no sense whatsoever.

.Any() should check under the hood whether the incoming IEnumerable is in fact an array, in which case it should do .Length != 0 automatically. LINQ methods already do this sort of optimization-based-on-the-type extensively, as far as I know.

We shouldn't be telling users to change their code in these cases, .Any() is without doubt clearer and more readable than .Length != 0. This was such a strange decision.

[stephentoub]

.Any() should check under the hood whether the incoming IEnumerable is in fact an array, in which case it should do .Length != 0 automatically. LINQ methods already do this sort of optimization-based-on-the-type extensively, as far as I know.

It does, and it's still more costly than the caller just doing it itself.

[aradalvand]

It does

Good to know.

and it's still more costly than the caller just doing it itself.

Obviously, but then again if Any() merits an analyzer/warning, so does every other LINQ method that does type-checking under the hood — in cases where the caller knows the specific type of the collection, no? Why make an exception for .Any() in this regard?
If you're in such a hot path that even the performance overhead of .Any() makes a difference, you shouldn't be using any LINQ anyway. But in most cases, the code clarity that LINQ methods offer (including .Any()) trumps the performance cost, that's why they exist in the first place. I don't understand why .Any() is being singled out here.

[mrahhal]

I don't understand why .Any() is being singled out here.

Likely because it's the most common usage in linq.

But I agree that, at least, this probably should have a lower diagnostic level than Suggestion by default. Most code won't benefit from this particular optimization, any code that is sensitive enough to benefit would probably be already aware of this. I also feel that Any() has become more readable overtime than Length/Count == 0. Maybe because it's a common interface that doesn't need to change when you're switching impls from arrays to collections and vice versa as you're developing. Having largely irrelevant squiggles randomly popping up isn't pretty, I always end up silencing this particular family of diags.

[Bellarmine-Head]

Just found this (via Nick Chapsas).

Re. #78606 - it's a pity that the word "ordinal" does not appear even once... especially wrt ignore-case. I think it should have featured in the discussion.

This table looks wrong to me. In every case, the assumption is that the string is linguistic, or is "linguistically relevant".

I refer you to:- https://learn.microsoft.com/en-us/dotnet/standard/base-types/best-practices-strings

Specifially I refer you to: https://learn.microsoft.com/en-us/dotnet/standard/base-types/best-practices-strings#choosing-a-stringcomparison-member-for-your-method-call

For over 20 years, my case-insensitve string comparisons have been wrt

• Case-insensitive internal identifiers.
• Case-insensitive identifiers in standards such as XML and HTTP.
• File paths.
• Registry keys and values.
• Environment variables.
• Resource identifiers (for example, handle names).
• Case-insensitive security-related settings.

ergo... StringComparison.OrdinalIgnoreCase.

The number of times I have had to worry about case-insensitivity in linguistic data that's input by the user or displayed to the user: zero.

The more common case (by far) for case-insensitive string comparisons is for non-linguistic strings. And getting it right for non-linguistic strings is important for security.

In every single case in the table, I'd go for OrdinalIgnoreCase as the default analyzer recommendation, with the caveat that "if the string is linguistic, go for culture-ignore-case".

[mirmostafa]

Instead of sending warning when using .Any() in arrays and list, why not to add the following bunch of code to the .Net sources:

    public static bool Any<T>(this IList<T> source) =>
        source.Count != 0;
    public static bool Any<T>(this T[] source) =>
        source.Length != 0;
    public static bool Any<T>(this ICollection source) =>
        source.Count != 0;