-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Refactor out TargetFramework concept from Microsoft.Interop.SourceGeneration #92301
Refactor out TargetFramework concept from Microsoft.Interop.SourceGeneration #92301
Conversation
…s, and generator factory keys.
…tFramework logic into LibraryImportGenerator.
Tagging subscribers to this area: @dotnet/interop-contrib Issue DetailsRefactor the concept of TargetFramework out of Micrsoft.Interop.SourceGeneration. Replace it with a CodeEmitOptions struct for us to introduce emit switches based on TFM features (in particular, the ability to skip initialization of locals was only introduced in .NET 5, so we need to have a switch for it). As all other use cases of the TFM are downlevel-support-specific in LibraryImportGenerator, move the TFM types into LibraryImportGenerator.
|
I started getting a wall of errors on dotnet/runtime builds today:
Could it be related? |
Apparently the errors went away after the next arcade version bump commit... I just happened to land in the window in-between. Sorry for the noise. |
Any chance you can send me the commit sha that failed? And did this fail in VS or on the command line? We shouldn't be hitting failures like that ever. |
It was 24ead90 but I cannot reproduce it anymore. I simply woke up and tried to run |
Not sure what is going on but it started happening again... commit bbe5c66, macOS, running
The build passed, but the second command did not:
...and now any subsequent attempt to build (even just Yesterday I deleted the full NuGet cache and dotnet installation. If you have any tips how to analyze this I would certainly appreciate it. I had a theory why is it happening (semi-)randomly... I tend to have the root of the repository opened in VS Code, and I have the C# and C# Dev Kit extensions installed there. I though it may trigger some kind of restore that brings the repository into uncompilable state. However, closing VS Code and cleaning the repo and NuGet cache didn't help. |
...and the problem is gone again after machine restart. Could it be MSBuild node reuse (or Roslyn process sharing?) kicking in and hitting a shared process that has a wrong version of the library already loaded? |
I think node reuse might be the problem, but the builds should be isolated. If it happens again, can you email me a binlog at the email in my profile? |
Sure. I tried to disable MSBuild node reuse to no effect, so I am leaning towards putting the blame on Roslyn Compiler Server. Running |
This appears to be happening because other analyzers build using the SDK's ref-pack: runtime/src/libraries/Directory.Build.targets Lines 58 to 59 in 97a51cc
But they aren't doing anything to disable the generators from that. So the roslyn process gets a mix of the LKG generators and live built generator assemblies in process. I think the fix here is to disable all the generators from the ref-pack. |
Refactor the concept of TargetFramework out of Micrsoft.Interop.SourceGeneration. Replace it with a CodeEmitOptions struct for us to introduce emit switches based on TFM features (in particular, the ability to skip initialization of locals was only introduced in .NET 5, so we need to have a switch for it). As all other use cases of the TFM are downlevel-support-specific in LibraryImportGenerator, move the TFM types into LibraryImportGenerator.