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

EnC - Report rude edit when a user adds an AsyncMethodBuild attribute #55877

Merged
merged 6 commits into from
Aug 30, 2021

Conversation

davidwengier
Copy link
Contributor

Part of C# 10 support

@davidwengier davidwengier requested a review from tmat August 25, 2021 05:36
@davidwengier davidwengier requested a review from a team as a code owner August 25, 2021 05:36
@davidwengier davidwengier changed the title Report rude edit when a user adds an AsyncMethodBuild attribute EnC - Report rude edit when a user adds an AsyncMethodBuild attribute Aug 25, 2021
// * When the target is a type, for any await call to a method that returns that type
//
// Therefore applying this attribute can cause unbounded changes to emitted code anywhere in a project
// which EnC wouldn't pick up, so we block it with a rude edit
Copy link
Member

Choose a reason for hiding this comment

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

Didn't we say we are ok with that in general, similar to changing a using directive?

Copy link
Member

@tmat tmat Aug 25, 2021

Choose a reason for hiding this comment

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

It's true that adding/removing the attribute wouldn't have the desired effect unless one also changes the call sites, so it might be a bit confusing. But I wonder if we have to block it because of that. Maybe the user is actually planning on updating the call site. Perhaps file an issue to improve the experience by using FAR to locate the call sites and report warnings? Not worth doing since it's unlikely that someone cares, but just so we track it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is certainly an argument to just do nothing here, like with using directives, but I feel like with those the most likely scenarios are either directly modifying code (eg, adding a using via completion etc.) or an ambiguous type error. It seems pretty convoluted to get a situation where a using is added, which changes semantic meaning, but causes no diagnostics.

With this attribute every scenario falls in to the latter bucket: You add it, and there is no indication that it won't do what you expect.

I don't feel strongly about it either way, so I'm fine to just abandon this if you don't think its worth it.

Copy link
Member

Choose a reason for hiding this comment

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

Actually, you are right that this should be rude edit - an existing unupdated call site would throw MethodMissingException if this is allowed since we change the method signature, right?

Copy link
Member

Choose a reason for hiding this comment

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

Please, add a test. Probably should test all the attributes listed above as well (Theory).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is a test that covers this switch, but a theory for all of the cases is a good idea.

Copy link
Contributor Author

@davidwengier davidwengier Aug 25, 2021

Choose a reason for hiding this comment

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

an existing unupdated call site would throw MethodMissingException if this is allowed since we change the method signature, right?

I don't think I follow. An unupdated call site would just continue to use the old method builder, not the user specified one.
See: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-10.0/async-method-builders#execution

Copy link
Member

Choose a reason for hiding this comment

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

Oh, for some reason I thought it has effect on the caller. Never mind. If you change it on a method then the method is recompiled so it makes a difference, right? If you change it on a type we don't recompile all of the type's async methods, so that might be problematic.

Copy link
Contributor Author

@davidwengier davidwengier Aug 25, 2021

Choose a reason for hiding this comment

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

For a method I think you're right, and actually I was mistaken and my comment is wrong, so we could allow it for methods. I read it as called to the method for some reason.

If you change it on a type we don't recompile all of the type's async methods

It's worse actually, for types we would need to recompile any async method that returns that type (though that isn't a C# 10 change)

@davidwengier davidwengier enabled auto-merge (squash) August 27, 2021 08:13
Copy link
Member

@tmat tmat left a comment

Choose a reason for hiding this comment

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

:shipit:

@davidwengier davidwengier enabled auto-merge (squash) August 30, 2021 19:54
@davidwengier davidwengier merged commit 023d3ca into dotnet:main Aug 30, 2021
@ghost ghost added this to the Next milestone Aug 30, 2021
@davidwengier davidwengier deleted the EnCAsyncMethodBuilder branch August 30, 2021 20:50
@dibarbet dibarbet modified the milestones: Next, 17.0.P4 Aug 31, 2021
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.

3 participants