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

Import all custom modifiers and move their validation to compilers. #45220

Merged
merged 2 commits into from
Jun 16, 2020

Conversation

AlekseyTs
Copy link
Contributor

Closes #44671.

@AlekseyTs
Copy link
Contributor Author

@jcouv, @cston, @RikkiGibson, @dotnet/roslyn-compiler Please review

DeriveUseSiteDiagnosticFromCustomModifiers(ref result, param.RefCustomModifiers);
return DeriveUseSiteDiagnosticFromType(ref result, param.TypeWithAnnotations, AllowedRequiredModifierType.None) ||
DeriveUseSiteDiagnosticFromCustomModifiers(ref result, param.RefCustomModifiers,
this is MethodSymbol method && method.MethodKind == MethodKind.FunctionPointerSignature ?
Copy link
Member

@333fred 333fred Jun 16, 2020

Choose a reason for hiding this comment

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

It feels like this would be better as a parameter to DeriveUseSiteDiagnosticFromParameter, rather than calculated internally here. #Resolved

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 feels like this would be better as a parameter to DeriveUseSiteDiagnosticFromParameter, rather than calculated internally here.

I do not think so. We have all information to reliably make the decision here, why would we want the consumer to to do extra work, given that the condition is still going to be pretty much the same.


In reply to: 441015421 [](ancestors = 441015421)

Copy link
Member

Choose a reason for hiding this comment

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

We have all information to reliably make the decision here, why would we want the consumer to to do extra work, given that the condition is still going to be pretty much the same.

Because it feels like this is the wrong place to make that decision. We can enumerate the possibilities here today, but that feels fragile. It seems like the best place to state the required modifiers is the component that actually cares about that requirement. I'm not going to block this PR on it as it's minor, but it really doesn't feel like the appropriate location.


In reply to: 441020808 [](ancestors = 441020808,441015421)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because it feels like this is the wrong place to make that decision. We can enumerate the possibilities here today, but that feels fragile. It seems like the best place to state the required modifiers is the component that actually cares about that requirement. I'm not going to block this PR on it as it's minor, but it really doesn't feel like the appropriate location.

Even if we assume that the code is fragile, which I do not agree with. I am failing to see how duplication of the same logic in many places makes the code less fragile.


In reply to: 441029178 [](ancestors = 441029178,441020808,441015421)

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

@AlekseyTs
Copy link
Contributor Author

@jcouv, @cston, @RikkiGibson, @dotnet/roslyn-compiler Please review, need a second sign-off

@@ -334,7 +334,7 @@ private FunctionPointerMethodSymbol(CallingConvention callingConvention, Immutab
RefCustomModifiers = CSharpCustomModifier.Convert(retInfo.RefCustomModifiers);
CallingConvention = callingConvention;
ReturnTypeWithAnnotations = returnType;
RefKind = getRefKind(retInfo, RefCustomModifiers, RefKind.RefReadOnly);
RefKind = getRefKind(retInfo, RefCustomModifiers, RefKind.RefReadOnly, RefKind.Ref);
Copy link
Member

Choose a reason for hiding this comment

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

RefKind.Ref); [](start = 83, length = 13)

I didn't understand this. Why are we mapping OutAttribute to RefKind.Ref?

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 didn't understand this. Why are we mapping OutAttribute to RefKind.Ref?

What would you expect us to do here?


In reply to: 441161001 [](ancestors = 441161001)

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure, that's why I'm asking for clarification. Why are we mapping OutAttribute to RefKind.Ref?

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'm not sure, that's why I'm asking for clarification. Why are we mapping OutAttribute to RefKind.Ref?

What do you think is a better option?


In reply to: 441164767 [](ancestors = 441164767)

@@ -351,9 +351,9 @@ class CBar : IFoo // CS0535 * 2
// (7,14): error CS0535: 'CBar' does not implement interface member 'IFoo.M<T>(T)'
// class CBar : IFoo // CS0535 * 2
Diagnostic(ErrorCode.ERR_UnimplementedInterfaceMember, "IFoo").WithArguments("CBar", "Metadata.IFoo.M<T>(T)").WithLocation(7, 14),
// (2,21): error CS0570: 'IFooAmbiguous<T, R>.M(?)' is not supported by the language
Copy link
Member

@jcouv jcouv Jun 16, 2020

Choose a reason for hiding this comment

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

? [](start = 52, length = 1)

nit: I like that we load the type even if there is a modifier problem. But it feels like the change in diagnostics is making troubleshooting worse, as the ? would at least point users closer to the source of the problem. We can tweak if we get feedback... #Resolved

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 feels like the change in diagnostics is making troubleshooting worse, as the ? would at least point users closer to the source of the problem. We can tweak if we get feedback...

I don't think a "?" actually points to any specific source of the problem


In reply to: 441162316 [](ancestors = 441162316)

Copy link
Contributor Author

@AlekseyTs AlekseyTs Jun 16, 2020

Choose a reason for hiding this comment

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

I think the error is actually more informative now because you can use the info to locate the member in metadata. The signature is not mangled


In reply to: 441163418 [](ancestors = 441163418,441162316)

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

@jcouv jcouv self-assigned this Jun 16, 2020
@AlekseyTs AlekseyTs merged commit 6e07682 into dotnet:master Jun 16, 2020
@ghost ghost added this to the Next milestone Jun 16, 2020
@dibarbet dibarbet modified the milestones: Next, 16.7.P4 Jun 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

IsExternalInit decoding should be more restrictive
4 participants