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

[Group 1] Enable nullable annotations for Microsoft.Extensions.Primitives #57395

Merged
merged 21 commits into from
Aug 19, 2021

Conversation

maxkoshevoi
Copy link
Contributor

@maxkoshevoi maxkoshevoi commented Aug 14, 2021

Related to #43605

@dotnet-issue-labeler
Copy link

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label Aug 14, 2021
@maxkoshevoi maxkoshevoi changed the title Annotate Microsoft.Extensions.Primitives for nullable reference types Enable nullable annotations for Microsoft.Extensions.Primitives Aug 14, 2021
public override bool Equals(object obj) { throw null; }
public bool Equals(string text) { throw null; }
public override bool Equals(object? obj) { throw null; }
public bool Equals(string? text) { throw null; }
Copy link
Member

Choose a reason for hiding this comment

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

Doesn't this throw for null?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It doesn't allow me to make it non-nullable...

image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Interestingly, in implementation text is non-nullable and everything compiles fine

Copy link
Member

Choose a reason for hiding this comment

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

It doesn't allow me to make it non-nullable...

You need to change the type of the interface being implemented to IEquatable<string?>.

in implementation text is non-nullable and everything compiles fine

Yes, because the code never tries to dereference a maybe-null value. The first thing the code does is check whether it's null and throw if it is.

Copy link
Contributor Author

@maxkoshevoi maxkoshevoi Aug 14, 2021

Choose a reason for hiding this comment

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

You need to change the type of the interface being implemented to IEquatable<string?>

Still doesn't allow non-nullable text

image

Copy link
Member

Choose a reason for hiding this comment

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

Sorry, I misread what you'd written. IEquatable<T> is defined to expect Equals always allows null (it accepts a T?), which is why this is complaining about trying to specify a non-nullable value. I think the implementation should be changed to return false rather than throwing, and then typed as string?, but I'll defer here to @dotnet/area-microsoft-extensions area owners.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Made it return false.

@maxkoshevoi maxkoshevoi changed the title Enable nullable annotations for Microsoft.Extensions.Primitives [Group 1] Enable nullable annotations for Microsoft.Extensions.Primitives Aug 15, 2021
@ghost
Copy link

ghost commented Aug 16, 2021

Tagging subscribers to this area: @eerhardt, @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

Related to #43605

Author: maxkoshevoi
Assignees: -
Labels:

new-api-needs-documentation, area-Extensions-Primitives, community-contribution

Milestone: -

@maryamariyan maryamariyan added this to the 7.0.0 milestone Aug 16, 2021
Copy link
Member

@krwq krwq left a comment

Choose a reason for hiding this comment

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

LGTM, thank you a lot for this contribution!

Copy link
Member

@eerhardt eerhardt 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 for the contribution!

@eerhardt eerhardt merged commit edfed86 into dotnet:main Aug 19, 2021
@maxkoshevoi maxkoshevoi deleted the mk/43605-primitives branch August 19, 2021 21:42
@BrennanConroy
Copy link
Member

I think StringSegment needs another look, Buffer is allowed to be null so you can distinguish between string.Empty and a null string.
You can see that null is a valid value because there is code specific to Buffer being null

public bool HasValue => Buffer != null;


public string? Value => HasValue ? Buffer.Substring(Offset, Length) : null;

This is causing issues in AspNetCore when trying to consume the Runtime update because we expect to be able to pass null to StringSegment. dotnet/aspnetcore#35547

@maxkoshevoi
Copy link
Contributor Author

Oh, I see. Second constructor thrown me off (it throws if buffer is null, but that's because we are trying to get only part of it).
I'll create a PR to make buffer nullable shortly.

@maxkoshevoi
Copy link
Contributor Author

maxkoshevoi commented Aug 20, 2021

Shouldn't new StringSegment(null).Equals((string?)null); return true than?
In old implementation it throws, and after this PR it returns false (which might need to be changed back to throwing now that buffer can be null).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Extensions-Primitives community-contribution Indicates that the PR has been added by a community member new-api-needs-documentation
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

6 participants