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

[release/7.0] Don't generate a nearly empty file #77187

Merged
merged 2 commits into from
Nov 9, 2022

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Oct 18, 2022

Backport of #76835 to release/7.0

/cc @AaronRobinsonMSFT @jasonmalinowski

Customer Impact

.NET 7 is shipping with some new Roslyn source generators, specifically the JS Import Generator and the LibraryImport generators. Unlike other generators we’ve shipped in the past, if these generators have nothing to generate, they still “generate” an empty file which is passed to Roslyn. This has two notable impacts:

  1. We’re shipping Visual Studio 17.4 with some new telemetry for source generators; one of the pieces of information requested from the runtime team was to include the number of files generated in sessions, which means we should be able to get a decent sense of what fraction of solutions in the wild are actually using the benefits of different generators. Since these always produce exactly one file even if there isn’t any actual output, we won’t be able to get usable telemetry for these generators until this is fixed. We do have the ability to filter out generators with specific file versions, so we should be able to remove the GA generator versions once we take this change.
  2. It creates some additional overhead in the Roslyn IDE: once generators produce output we have to manage two “versions” of the project: the user’s code without the generated content and then the version with the generated content. Although that overhead isn’t the worst (and unavoidable once generators are actually being consumed), these generators generating an almost-empty file means we’re paying that overhead in 7.0 projects even if we don’t need to.

Testing

Unit tests were added.

Risk

Low -- the only behavior change to the generator is instead of outputting an empty file with a "autogenerated" comment, we output no file at all. No change is otherwise made to the generator behavior.

When generators are running in the Visual Studio IDE, there's some
overhead to having to manage a project that actually has generated
output. It requires us to maintain two Roslyn Compilation objects,
each which have their own symbol information. These interop generators
are producing a file that's effectively empty (just an <auto-generated>
comment on the top), and since they're installed in all .NET 7.0
applications, they are the reason we'll be having to manage more memory
than before. Since the fix is simple enough to only generate the output
if necessary, we should do so.

This also will help with telemetry, since we have telemetry that lets us
tracking in the wild which generators are producing how many files;
if we're always producing exactly one file we won't know how many
sessions out there are actually using this generator in a meaningful
way.
@ghost
Copy link

ghost commented Oct 18, 2022

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

Backport of #76835 to release/7.0

/cc @AaronRobinsonMSFT @jasonmalinowski

Customer Impact

Testing

Risk

IMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.

Author: github-actions[bot]
Assignees: -
Labels:

area-System.Runtime.InteropServices

Milestone: -

@carlossanlop
Copy link
Member

@jasonmalinowski @AaronRobinsonMSFT when this is ready, please add the servicing-consider label, get a code review sign-off, and send an email to Tactics requesting merge approval.

@jasonmalinowski jasonmalinowski added the Servicing-consider Issue for next servicing release review label Nov 2, 2022
@ericstj
Copy link
Member

ericstj commented Nov 2, 2022

I wonder if we can collect these common source generator requirements in the cookbook and in common/shared tests? We've definitely had a set of generic requirements around generators behavior / performance. CC @joperezr @sharwell @CyrusNajmabadi @chsienki

@carlossanlop
Copy link
Member

@AaronRobinsonMSFT / @jkoritzinsky / @elinor-fung can we please get a code review sign off here?

@carlossanlop
Copy link
Member

@jasonmalinowski please send the email to Tactics if possible, although since you already added the label, we will discuss it in the meeting tomorrow. Sending the email never hurts 😄 .

@jasonmalinowski
Copy link
Member

@carlossanlop: I sent one yesterday evening, did it not get through somehow?

@carlossanlop
Copy link
Member

@carlossanlop: I sent one yesterday evening, did it not get through somehow?

Oh I see why I couldn't find the email: the subject is different to the title of this PR: "Tweak to change output of import generators if the generators aren't being used".

@carlossanlop carlossanlop added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Nov 3, 2022
@carlossanlop carlossanlop added this to the 7.0.x milestone Nov 3, 2022
@carlossanlop
Copy link
Member

Approved by Tactics via email.

All that's left is addressing the open feedback.

@carlossanlop
Copy link
Member

CI failure unrelated (unable to load the Json DLL in a Console test).
Feedback addressed. Approved by Tactics. Signed off.
No OOB package authoring changes needed (the related csproj files are either explicitly set to IsPackable=false or it's not mentioned).
Ready to merge. :shipit:

@carlossanlop carlossanlop merged commit 00816bf into release/7.0 Nov 9, 2022
@carlossanlop carlossanlop deleted the backport/pr-76835-to-release/7.0 branch November 9, 2022 20:28
@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants