Skip to content
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

Merged
merged 19 commits into from
Jan 20, 2022

Conversation

alrz
Copy link
Contributor

@alrz alrz commented Oct 28, 2021

Spec is updated as follows:

The member that makes the type sliceable is assumed to be well-behaved, that is, the return value is never null and that it is a proper subslice of the containing list.

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

@ghost ghost added the Community The pull request was submitted by a contributor who is not a Microsoft employee. label Oct 28, 2021
@jcouv
Copy link
Member

jcouv commented Oct 30, 2021

I'm not following. The LDM decision was to honor the annotation on Slice method. The current behavior is correct, no?

@alrz

This comment has been minimized.

@alrz alrz marked this pull request as ready for review November 4, 2021 09:37
@alrz alrz requested a review from a team as a code owner November 4, 2021 09:37
@jcouv jcouv self-assigned this Nov 9, 2021
@alrz alrz requested a review from jcouv November 10, 2021 19:06
@alrz alrz changed the title Slice value is always assumed to be not null List patterns: Slice value is assumed to be never null Nov 10, 2021
Copy link
Member

@jcouv jcouv left a 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)

@alrz alrz requested review from jcouv and 333fred January 11, 2022 16:55
Copy link
Member

@jcouv jcouv left a 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)

@jcouv
Copy link
Member

jcouv commented Jan 11, 2022

@333fred @AlekseyTs @dotnet/roslyn-compiler for second review. Thanks

Copy link
Member

@333fred 333fred left a 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)
Copy link
Member

@333fred 333fred Jan 12, 2022

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

Copy link
Contributor Author

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?

Copy link
Contributor Author

@alrz alrz Jan 12, 2022

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.

Copy link
Member

@jcouv jcouv Jan 18, 2022

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.

Copy link
Contributor Author

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.

@AlekseyTs
Copy link
Contributor

Done with review pass (commit 17)

Comment on lines 516 to +517
addToTempMap(output, outputSlot, type.Type);
this.State[outputSlot] = NullableFlowState.NotNull; // Slice value is assumed to be never null
Copy link
Contributor Author

@alrz alrz Jan 19, 2022

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?)

Copy link
Member

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)
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Member

@jcouv jcouv left a 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

Copy link
Member

@333fred 333fred left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (commit 19)

@jcouv jcouv enabled auto-merge (squash) January 19, 2022 21:31
@jcouv jcouv merged commit 305a91c into dotnet:main Jan 20, 2022
@ghost ghost added this to the Next milestone Jan 20, 2022
@jcouv
Copy link
Member

jcouv commented Jan 20, 2022

Thanks @alrz! :-)

333fred added a commit to 333fred/roslyn that referenced this pull request Jan 21, 2022
* 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)
  ...
@RikkiGibson RikkiGibson modified the milestones: Next, 17.2.P1 Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Community The pull request was submitted by a contributor who is not a Microsoft employee. New Feature - List Patterns
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants