Don't cache the Compilation object in steps in the interop source generators #76474
Conversation
…Environment to avoid rooting the compilation. Update all generators to follow suit and add a test in LibraryImportGenerator to validate that we don't keep the compilation alive.
jkoritzinsky
added
area-System.Runtime.InteropServices
source-generator
|
Tagging subscribers to this area: @dotnet/interop-contrib Issue DetailsThe interop source generators today use a custom Equals implementation to ignore the Compilation object that is stored in the StubEnvironment object as part of the "incremental" data model. Our steps are still incremental, but this change can cause an indeterminate amount of Compilation objects to be kept alive significantly longer, which increases memory load in VS and the Roslyn OOP service. This change makes one scenario slightly less incremental (it will regenerate the source for some stubs when the file a stub is in is changed), but this will overall be an improvement in memory usage for our generators. Extracted out of #68276
|
...ies/System.Runtime.InteropServices/gen/ComInterfaceGenerator/ComInterfaceGeneratorHelpers.cs
Outdated
Show resolved
Hide resolved
...Runtime.InteropServices/tests/LibraryImportGenerator.UnitTests/IncrementalGenerationTests.cs
Show resolved
Hide resolved
...untime.InteropServices/gen/Microsoft.Interop.SourceGeneration/SequenceEqualImmutableArray.cs
Show resolved
Hide resolved
|
/backport to release/7.0 |
|
/backport to release/7.0 |
|
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3464895866 |
|
@jkoritzinsky backporting to release/7.0 failed, the patch most likely resulted in conflicts: $ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Directly pass along target framework kind and version instead of StubEnvironment to avoid rooting the compilation. Update all generators to follow suit and add a test in LibraryImportGenerator to validate that we don't keep the compilation alive.
Using index info to reconstruct a base tree...
M src/libraries/System.Runtime.InteropServices.JavaScript/gen/JSImportGenerator/JSExportCodeGenerator.cs
M src/libraries/System.Runtime.InteropServices.JavaScript/gen/JSImportGenerator/JSExportGenerator.cs
M src/libraries/System.Runtime.InteropServices.JavaScript/gen/JSImportGenerator/JSImportCodeGenerator.cs
M src/libraries/System.Runtime.InteropServices.JavaScript/gen/JSImportGenerator/JSImportGenerator.cs
M src/libraries/System.Runtime.InteropServices/gen/LibraryImportGenerator/Analyzers/ConvertToLibraryImportAnalyzer.cs
M src/libraries/System.Runtime.InteropServices/gen/LibraryImportGenerator/LibraryImportGenerator.cs
M src/libraries/System.Runtime.InteropServices/gen/LibraryImportGenerator/LibraryImportGenerator.csproj
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Runtime.InteropServices/gen/LibraryImportGenerator/LibraryImportGenerator.csproj
CONFLICT (content): Merge conflict in src/libraries/System.Runtime.InteropServices/gen/LibraryImportGenerator/LibraryImportGenerator.csproj
Auto-merging src/libraries/System.Runtime.InteropServices/gen/LibraryImportGenerator/LibraryImportGenerator.cs
Auto-merging src/libraries/System.Runtime.InteropServices/gen/LibraryImportGenerator/Analyzers/ConvertToLibraryImportAnalyzer.cs
Auto-merging src/libraries/System.Runtime.InteropServices.JavaScript/gen/JSImportGenerator/JSImportGenerator.cs
CONFLICT (content): Merge conflict in src/libraries/System.Runtime.InteropServices.JavaScript/gen/JSImportGenerator/JSImportGenerator.cs
Auto-merging src/libraries/System.Runtime.InteropServices.JavaScript/gen/JSImportGenerator/JSImportCodeGenerator.cs
Auto-merging src/libraries/System.Runtime.InteropServices.JavaScript/gen/JSImportGenerator/JSExportGenerator.cs
CONFLICT (content): Merge conflict in src/libraries/System.Runtime.InteropServices.JavaScript/gen/JSImportGenerator/JSExportGenerator.cs
Auto-merging src/libraries/System.Runtime.InteropServices.JavaScript/gen/JSImportGenerator/JSExportCodeGenerator.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Directly pass along target framework kind and version instead of StubEnvironment to avoid rooting the compilation. Update all generators to follow suit and add a test in LibraryImportGenerator to validate that we don't keep the compilation alive.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128Please backport manually! |
|
@jkoritzinsky an error occurred while backporting to release/7.0, please check the run log for details! Error: git am failed, most likely due to a merge conflict. |
|
Since the backport failed, I'll handle backporting this manually. To make sure we cover all cases of the "keeping the Compilation object alive" problem, I suggest we wait to backport this until #78242 is also fixed. |
ghost
locked as resolved and limited conversation to collaborators
The interop source generators today use a custom Equals implementation to ignore the Compilation object that is stored in the StubEnvironment object as part of the "incremental" data model. Our steps are still incremental, but this change can cause an indeterminate amount of Compilation objects to be kept alive significantly longer, which increases memory load in VS and the Roslyn OOP service. This change makes one scenario slightly less incremental (it will regenerate the source for some stubs when the file a stub is in is changed), but this will overall be an improvement in memory usage for our generators.
Extracted out of #68276
It might be worth pushing this PR into 7.0 or 7.0.1 due to the VS impact.