-
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
List patterns: Slice value is assumed to be never null #57457
Conversation
src/Compilers/CSharp/Test/Semantic/Semantics/PatternMatchingTests_ListPatterns.cs
Outdated
Show resolved
Hide resolved
I'm not following. The LDM decision was to honor the annotation on Slice method. The current behavior is correct, no? |
This comment has been minimized.
This comment has been minimized.
src/Compilers/CSharp/Test/Semantic/Semantics/PatternMatchingTests_ListPatterns.cs
Show resolved
Hide resolved
src/Compilers/CSharp/Test/Semantic/Semantics/PatternMatchingTestBase.cs
Outdated
Show resolved
Hide resolved
src/Compilers/CSharp/Test/Semantic/Semantics/PatternMatchingTests_ListPatterns.cs
Outdated
Show resolved
Hide resolved
src/Compilers/CSharp/Test/Semantic/Semantics/PatternMatchingTests_ListPatterns.cs
Outdated
Show resolved
Hide resolved
src/Compilers/CSharp/Test/Semantic/Semantics/PatternMatchingTests_ListPatterns.cs
Outdated
Show resolved
Hide resolved
src/Compilers/CSharp/Test/Semantic/Semantics/PatternMatchingTests_ListPatterns.cs
Outdated
Show resolved
Hide resolved
src/Compilers/CSharp/Test/Semantic/Semantics/PatternMatchingTests_ListPatterns.cs
Outdated
Show resolved
Hide resolved
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.
Done with review pass (iteration 9)
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 17)
@333fred @AlekseyTs @dotnet/roslyn-compiler for second review. 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.
Done review pass (commit 17)
Diagnostic(ErrorCode.WRN_NullReferenceReceiver, "slice").WithLocation(12, 13), | ||
// (14,13): warning CS8602: Dereference of a possibly null reference. | ||
// list.ToString(); | ||
Diagnostic(ErrorCode.WRN_NullReferenceReceiver, "list").WithLocation(14, 13) |
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'm not sure I understand this one. Shouldn't the []
pattern say that it's a non-null slice, since it has to dereference the slice to determine if the slice is empty? #Closed
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. I'd defer to @jcouv for that. My solution was to ignore and report the annotation on the return type.
If we consider slice.Length evaluation (or any other) as a dereference with no warning on forthcoming derefs, shouldn't we inform the user about it?
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 think we can do something in between: ignore and report only if there's a dereference i.e. when the result is being used - that would exclude var patterns. Not sure how that would play out with Nullable<T>
as the result.
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.
Thanks for spotting this. There's indeed a good question here.
From the LDM notes: "We will adjust our expectations around slice patterns to assume that Slice will never return a null value, and we will not insert a null test into the reachability or codegen DAGs."
I think it should follow that both the .. var slice
and .. [] slice2
cases should yield not-null state for those variables.
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.
@jcouv Can you please take another look? thanks.
src/Compilers/CSharp/Test/Semantic/Semantics/PatternMatchingTests_ListPatterns.cs
Show resolved
Hide resolved
src/Compilers/CSharp/Test/Semantic/Semantics/PatternMatchingTests_ListPatterns.cs
Show resolved
Hide resolved
Done with review pass (commit 17) |
addToTempMap(output, outputSlot, type.Type); | ||
this.State[outputSlot] = NullableFlowState.NotNull; // Slice value is assumed to be never null |
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.
❓ Should we also strip the annotation on the return type for semantic model?
I am not sure if hovering over [.. var variable]
shows a nullable type (probably shouldn't?)
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.
The var
will definitely have a ?
, because it always does. Theoretically, though, it should say that variable
is considered not null here.
@@ -3880,12 +3880,12 @@ public void M() | |||
rest.ToString(); // 1 | |||
|
|||
if (new C<int?>() is [1, ..var rest2]) | |||
rest2.Value.ToString(); // 2 | |||
rest2.Value.ToString(); // 2 (assumed not-null) |
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.
This isn't quite what I meant: the numbers are wrong, because warning 2 is no longer there.
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 renumbered the one you commented on. Will update the rest in the next commit.
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.
Done.
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 18).
Nit: some line-number comments in tests could be adjusted, if no longer producing a diagnostic
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 (commit 19)
Thanks @alrz! :-) |
* upstream/main: (1035 commits) Add missing header Mark IVSTypeScriptFormattingServiceImplementation as optional, but require it in the constructor Fix Go To Base for a symbol with a single metadata location (dotnet#58965) [EnC] Store entire spans instead of line deltas (dotnet#58831) Delete CodeAnalysisRules.ruleset (dotnet#58968) Allow xml docs to still be created when 'emit metadata only' is on. (dotnet#57667) Fix ParseVBErrorOrWarning (dotnet#47833) Update parameter nullability to match implementation Ensure CSharpUseParameterNullCheckingDiagnosticAnalyzer works with nullable parameters Add tests for issues fixed by previous PR (dotnet#58764) Update src/Features/CSharp/Portable/Completion/CompletionProviders/ExplicitInterfaceMemberCompletionProvider.CompletionSymbolDisplay.cs Disallow null checking discard parameters (dotnet#58952) Add extension method Escape type arguments Few fixes Update tests. Add Analyzers layer to CODEOWNERS Add formatting analyzer test for param nullchecking (dotnet#58936) Move reading HideAdvancedMembers option up (dotnet#58747) List patterns: Slice value is assumed to be never null (dotnet#57457) ...
Spec is updated as follows:
In a nullable-enabled context, the annotation on the output type is ignored to avoid producing nonsensical warnings.(no longer needed to ignore, we're emitting the test but assuming the false branch is unreachable)not an option.Updated LDM decision (ended up agreeing with this approach): dotnet/csharplang#5599
Test plan: #51289