Skip to content

Use the declared type to infer NullableContextOptions #15134

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

Merged
merged 2 commits into from
Oct 20, 2019

Conversation

pranavkm
Copy link
Contributor

Prior to this change MVC used the runtime type rather than the declared type to
determine the nullability of a property based on state. In the case of inheritance,
this can be erroneous since the declared type may have a different nullability context
than the model type.

This change addresses this by adding content to ModelIdentity that allows inspecting the
declared type.

  • Add an overload to ModelMetadataIdentity that allows flowing PropertyInfo
  • Use the declared type in DataAnnotationsMetadataProvider to determine nullability based on context.

Fixes #14812

Prior to this change MVC used the runtime type rather than the declared type to
determine the nullability of a property based on state. In the case of inheritance,
this can be erroneous since the declared type may have a different nullability context
than the model type.

This change addresses this by adding content to `ModelIdentity` that allows inspecting the
declared type.

* Add an overload to `ModelMetadataIdentity` that allows flowing `PropertyInfo`
* Use the declared type in `DataAnnotationsMetadataProvider` to determine nullability based on context.

Fixes #14812
@pranavkm pranavkm requested a review from rynowak October 17, 2019 22:49
Copy link

@NTaylorMullen NTaylorMullen left a comment

Choose a reason for hiding this comment

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

I mostly have dumb questions. Signing off since you know better 😉


if (HasNullableAttribute(context.PropertyAttributes, out var propertyHasNullableAttribute))
{
addInferredRequiredAttribute = propertyHasNullableAttribute;

Choose a reason for hiding this comment

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

Hmm, i'm confused, so if it has the nullable attribute then we DO add the required attribute? Isn't that backwards? I'm sure it's just me misunderstanding the code since your mass amount of tests show differently.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This might help: https://github.com/dotnet/roslyn/blob/master/docs/features/nullable-metadata.md#type-parameters, but essentially non-null is represented as [Nullable(1)]. HasNullableAttribute returns true if the attribute is present, the propertyHasNullableAttribute says if the value is 1.

else
{
addInferredRequiredAttribute = IsNullableReferenceType(
property.DeclaringType,

Choose a reason for hiding this comment

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

And just to clarify, this is the key piece that makes the customers scenario work correct?

Choose a reason for hiding this comment

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

Also, one last question when a user shadows a nullable property are there two model identitys? Aka, one for each property?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And just to clarify, this is the key piece that makes the customers scenario work correct?

Yeah. Well more like fixes our bug

Also, one last question when a user shadows a nullable property are there two model identitys? Aka, one for each property?

Yup. Although our property discovery will skip over shadowed properties: https://github.com/aspnet/AspNetCore/blob/master/src/Shared/PropertyHelper/PropertyHelper.cs#L441-L477

Copy link
Contributor

@mkArtakMSFT mkArtakMSFT left a comment

Choose a reason for hiding this comment

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

My main concern here is about the breaking change. Can we use a flag to avoid making a breaking change?

@mkArtakMSFT mkArtakMSFT added the area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates label Oct 19, 2019
@mkArtakMSFT mkArtakMSFT added this to the 3.1.0-preview2 milestone Oct 19, 2019
@pranavkm pranavkm merged commit cdae83e into release/3.1 Oct 20, 2019
@pranavkm pranavkm deleted the prkrishn/non-null branch October 20, 2019 13:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants