-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nullable ref type annotation fixes to analyzer APIs #43023
Conversation
Why are we allowing messageargs to be null? |
Roslyn always allowed this (and in some code paths explicitly pass |
@AArnott, it looks like some uses of |
I was only checking against Compilers.sln I see in Roslyn.sln there are some warnings. I'll look into it, @cston . |
src/Analyzers/Core/CodeFixes/PopulateSwitch/AbstractPopulateSwitchCodeFixProvider.cs
Outdated
Show resolved
Hide resolved
src/Analyzers/Core/CodeFixes/PopulateSwitch/AbstractPopulateSwitchCodeFixProvider.cs
Outdated
Show resolved
Hide resolved
This is permitted by the runtime code in prior versions, so the annotations should signify that.
Any other reviewers before this gets merged? |
@@ -53,7 +53,7 @@ private void AnalyzeOperation(OperationAnalysisContext context) | |||
!tree.OverlapsHiddenPosition(switchBlock.Span, context.CancellationToken)) | |||
{ | |||
Debug.Assert(missingCases || missingDefaultCase); | |||
var properties = ImmutableDictionary<string, string>.Empty | |||
var properties = ImmutableDictionary<string, string?>.Empty |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hrmm... who passes null for the value. I'd prefer we attempt to disallow that. If you make this non-null, can you point to any violators?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can restrict the values for the property bag to be non-null. I think I have seen some third party analyzers using null as a value for the property bag entry.
@@ -58,8 +58,8 @@ public sealed override Task RegisterCodeFixesAsync(CodeFixContext context) | |||
{ | |||
var diagnostic = context.Diagnostics.First(); | |||
var properties = diagnostic.Properties; | |||
var missingCases = bool.Parse(properties[PopulateSwitchStatementHelpers.MissingCases]); | |||
var missingDefaultCase = bool.Parse(properties[PopulateSwitchStatementHelpers.MissingDefaultCase]); | |||
var missingCases = bool.Parse(properties[PopulateSwitchStatementHelpers.MissingCases]!); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
! [](start = 97, length = 1)
We typically reserve the !
suppressions for things that are checked in the current method (directly or via straightforward helper method) but the compiler is unable to track.
For more complicated invariants, we use assertions instead (Debug.Assert(... is object);
or is { }
depending on preference).
These two (and two more below in this file) strike me as cases for assertions.
https://github.com/dotnet/roslyn/blob/master/docs/contributing/Nullable%20Annotations.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An assert seems unnecessary here since bool.Parse()
will throw an exception if the argument is null
.
In reply to: 405655126 [](ancestors = 405655126)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya. The ! was just to keep the compiler warning quiet so that the original behavior of throwing from bool.Parse would be preserved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM Thanks (iteration 2) with a nit.
The first commit is pretty straightforward as correct.
My second commit might be a bit more controversial, so I kept it separate in case we want to remove it from the branch before merging.