-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[main] Update dependencies from dotnet/runtime #41014
[main] Update dependencies from dotnet/runtime #41014
Conversation
…0519.2 Microsoft.Extensions.DependencyModel , Microsoft.Extensions.FileSystemGlobbing , Microsoft.Extensions.Logging , Microsoft.Extensions.Logging.Abstractions , Microsoft.Extensions.Logging.Console , Microsoft.NET.HostModel , Microsoft.NET.ILLink.Tasks , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.App.Ref , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.Platforms , System.CodeDom , System.Reflection.MetadataLoadContext , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.ServiceProcess.ServiceController , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.9.0 , VS.Redist.Common.NetCore.TargetingPack.x64.9.0 , Microsoft.SourceBuild.Intermediate.runtime.linux-x64 From Version 9.0.0-preview.5.24268.2 -> To Version 9.0.0-preview.5.24269.2
Notification for subscribed users from https://github.com/dotnet/runtime:@dotnet/dnr-codeflow Action requested: Please take a look at this failing automated dependency-flow pull request's checks; failures may be related to changes which originated in your repo.
|
@jozkee can you take a look at these failures? Perhaps related to the following: |
I had a look, SDK is still on an old compiler. I'm updating it and testing that it fixes the problem. |
…0520.2 Microsoft.Extensions.DependencyModel , Microsoft.Extensions.FileSystemGlobbing , Microsoft.Extensions.Logging , Microsoft.Extensions.Logging.Abstractions , Microsoft.Extensions.Logging.Console , Microsoft.NET.HostModel , Microsoft.NET.ILLink.Tasks , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.App.Ref , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.Platforms , System.CodeDom , System.Reflection.MetadataLoadContext , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.ServiceProcess.ServiceController , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.9.0 , VS.Redist.Common.NetCore.TargetingPack.x64.9.0 , Microsoft.SourceBuild.Intermediate.runtime.linux-x64 From Version 9.0.0-preview.5.24268.2 -> To Version 9.0.0-preview.5.24270.2
Fixing the new compiler warnings this introduced... |
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.
Test change LGTM
RazorTools tests seem to known timeout issue. #40074 Unified build failure is
So these are problems building WPF - likely with the new toolset. 🤔 It seems these WPF projects only pass a subset of references: The method the compiler is complaining about is in System.Memory: |
@ericstj I stepped into this issue as well on dotnet/runtime, you need to add a reference to System.Memory, see dotnet/runtime#100898 (comment). One of the new |
Right but we cannot do that because it's building WPF, which is not part of this repo. So those need to be added here: Then that hash of WPF needs to flow to this repo before it can update the compiler. I wish there was a way to workaround this @ViktorHofer @premun @MichaelSimons in case they have ideas. I wonder if |
The compiler does not demand its presence; the problem is that it really is being used. An existing codepath is now binding to a |
Ah, that makes more sense. I couldn't connect the dots to the syntax that was causing this. Would make it much easier if I got source and line info with the error. |
I agree, filed dotnet/roslyn#73596 for this. |
Looks like the change to WPF has further to flow than I thought. Trying out a patch file. |
The patch file worked but I need more than these two projects- that unblocked more that fail. Will need to see if I can repro the failure in WPF build to get all projects. |
Agree that is the cause here.
Based on the binlog view I agree. This is a common source of problems with moving to new .NET SDK. Essentially customers who were compiling without the complete reference graph, and getting away with it, get bit because a new feature, bug fix, etc ... cause the compiler to read members that require the missing references. Requiring the extra references is generally a "by design" resolution. Can see other instances of this we've hit in the past. If I could go back to C# 1.0, I'd force a warning whenever compilations had incomplete reference graphs. It is just inviting interesting behaviors like this and saving virtually nothing. 😦 |
…mpiler-9135.patch
There are more cases. Submitted dotnet/wpf#9140 |
…0521.1 Microsoft.Extensions.DependencyModel , Microsoft.Extensions.FileSystemGlobbing , Microsoft.Extensions.Logging , Microsoft.Extensions.Logging.Abstractions , Microsoft.Extensions.Logging.Console , Microsoft.NET.HostModel , Microsoft.NET.ILLink.Tasks , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.App.Ref , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.Platforms , System.CodeDom , System.Reflection.MetadataLoadContext , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.ServiceProcess.ServiceController , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.9.0 , VS.Redist.Common.NetCore.TargetingPack.x64.9.0 , Microsoft.SourceBuild.Intermediate.runtime.linux-x64 From Version 9.0.0-preview.5.24268.2 -> To Version 9.0.0-preview.5.24271.1
src/SourceBuild/patches/wpf/0001-more-system-memory-fixes.patch
Outdated
Show resolved
Hide resolved
1. Simplify scenario-tests test invocation by avoiding the intermediate NoTargets wrapper project. 2. Declare the dependency on extract-sdk-archive.proj in the test projects directly to avoid race conditions. #41014 failed because the scenario-tests already ran but the SDK test folder wasn't yet ready.
Another one: dotnet/wpf#9143 |
Here it's not a gap in the reference graph. For example https://github.com/dotnet/runtime/pull/101499/files#diff-cec8e6f471b4193246bdc0107b0dd7cbe131fb7fd189b288b37269c333d1171dR2170 is in System.Runtime and all its API is in System.Runtime (since it's the core assembly) but to call it you need to also reference System.Memory. This is why I think we should push MemoryMarshal down to System.Runtime. |
Ah okay. It's the impl class we're calling so not strictly a gap.
This seems like a reasonable solution. At the same time, customers that are manually subsetting the .NET reference (taking parts of it and not all) are playing with fire. There are other scenarios that can break when this is done. I'd separately be curious why WPF is doing this cause it's fragile to changes like this. |
This pull request updates the following dependencies
From https://github.com/dotnet/runtime