-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Separate the process of creating an event accessor parameter and the process of figuring out its type. #71497
Conversation
…process of figuring out its type. This allows us to perform lookup operations within the accessor without triggering the process of determining whether the event is a WINMD event. That process could request the list of containing type members while we are building the list, thus causing an unexpected circularity and an unexpected reentrancy into SourceMemberMethodSymbol.LazyMethodChecks on the same thread. Fixes dotnet#71400.
@dotnet/roslyn-compiler Please review |
@dotnet/roslyn-compiler For the second review |
2 similar comments
@dotnet/roslyn-compiler For the second review |
@dotnet/roslyn-compiler For the second review |
@dotnet/roslyn-compiler For the second review, please. |
@@ -122,9 +121,6 @@ protected sealed override void MethodChecks(BindingDiagnosticBag diagnostics) | |||
|
|||
_lazyReturnType = TypeWithAnnotations.Create(eventTokenType); | |||
this.SetReturnsVoid(returnsVoid: false); | |||
|
|||
var parameter = new SynthesizedAccessorValueParameterSymbol(this, _event.TypeWithAnnotations, 0); | |||
_lazyParameters = ImmutableArray.Create<ParameterSymbol>(parameter); |
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 assert here and below that the types remain as expected? For example here:
Debug.Assert(_parameters is [var p] && p.TypeWithAnnotations == _event.TypeWithAnnotation);
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 assert here and below that the types remain as expected? For example here
While we could do that. There will be a downside. That will mean that in DEBUG we will be synchronizing two processes that are going to be fully asynchronous in RELEASE, which might lead to a noticeable difference in behavior between the flavors. So, I am reluctant to add an assert like that.
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.
However, If you feel strongly about having the assert, I will add 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.
Thanks for the explanation - now I agree it's better without an assert here then.
This allows us to perform lookup operations within the accessor without triggering the process of determining whether the event is a WINMD event. That process could request the list of containing type members while we are building the list, thus causing an unexpected circularity and an unexpected reentrancy into SourceMemberMethodSymbol.LazyMethodChecks on the same thread.
Fixes #71400.