[main] Update dependencies from dotnet/arcade #67771
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![dotnet-maestro[bot]](https://avatars.githubusercontent.com/in/16706?s=60&v=4){kind=small}
…406.10 Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.ApiCompat , Microsoft.DotNet.XUnitExtensions , Microsoft.DotNet.GenAPI , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.GenFacades , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.Helix.Sdk From Version 2.5.1-beta.22179.1 -> To Version 2.5.1-beta.22206.10
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
This was referenced Apr 8, 2022
Closed
…6782-4440-8589-61f58f239059
lewing
changed the title
The generated path property for
`Pkgoptimization_windows_nt-x86_PGO_CoreCLR` seems to have a trailing
`\` now, on windows, which breaks the quoted use of the property:
`"-DCLR_CMAKE_OPTDATA_PATH="D:\a\_work\1\s\.packages\optimization.windows_nt-x86.pgo.coreclr\1.0.0-prerelease.22121.2\""`
Since this is a directory path being passed, it should be safe to always
trim the trailing `\`.
This manifests as:
```
Calling "D:\a\_work\1\s\src\coreclr\..\..\eng\native\gen-buildsys.cmd" "D:\a\_work\1\s\src\coreclr" "D:\a\_work\1\s\src\coreclr\..\..\artifacts\obj\coreclr\windows.x64.Release" vs2019 x64 "-DCMAKE_BUILD_TYPE=Release" "-DCLR_CMAKE_TARGET_ARCH=x64" "-DCLR_CMAKE_TARGET_OS=windows" "-DCLR_CMAKE_PGO_INSTRUMENT=0" "-DCLR_CMAKE_OPTDATA_PATH="D:\a\_work\1\s\.packages\optimization.windows_nt-x64.pgo.coreclr\1.0.0-prerelease.22121.2\"" "-DCLR_CMAKE_PGO_OPTIMIZE=1"
CMake Warning:
No source or binary directory provided. Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.
```
.. and ..
```
CMake Warning:
Manually-specified variables were not used by the project:
CLR_CMAKE_OPTDATA_PATH
```
and eventually:
```
##[error]BUILD: Error: unable to find generated native component build project
```
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I think this is #65750 . And it's breaking the tests here because now the sdk is being bumped to 7.0*. so, it is going to be a blocker for the sdk bump. cc @carlossanlop @dotnet/area-system-io-compression |
|
Some of the library failures are #58927 : |
it looks like this might be because helix is using an sdk before #65886 to zip the file which hopefully fixed the issue? |
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
based on dotnet/aspnetcore#40507 it looks like aspnetcore is using sdk 7.0.100-preview.3.22159.27 which resolved the issue. Let's open an issue / pr in arcade, that sdk is producing bad zips |
1 task
|
Opened dotnet/arcade#9011 |
Mirror version used in aspnetcore
|
/azp run runtime-extra-platforms,runtime-wasm |
I think we only do that for building the crossgen2 package itself, not for R2Ring the other packages. It's possible there's some bad interaction between side effects, though. |
|
/azp run runtime-extra-platforms,runtime-wasm |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
OK, in the latest runtime-dev-innerloop the installer build passed on Linux so hopefully the problem's been resolved somehow. |
…505.2 Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.ApiCompat , Microsoft.DotNet.XUnitExtensions , Microsoft.DotNet.GenAPI , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.GenFacades , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.Helix.Sdk From Version 2.5.1-beta.22179.1 -> To Version 2.5.1-beta.22255.2
|
/azp run runtime-extra-platforms,runtime-wasm |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
Merging main is proving to be a pretty good demonstration of how insufficient the PR tests are for catching regressions The wasm LibraryTests_AOT failure Assertion at /__w/1/s/src/mono/mono/mini/mini-runtime.c:3024 is
|
|
None of the mono failures appear to be related to this PR. the runtime-extra-platforms (Libraries Test Run release coreclr windows (x64,arm64) Release) failures are failures in resource lookup: Not sure if they are from this pr or just more expanded test coverage |
|
I'd prefer it if we don't merge main here until at the very least the rolling build is actually running again. This PR shouldn't continue to be used to debug problems in main. |
|
The resource lookup error above is usually a symptom of mismatched or broken runtime bits. It tries to throw an AccessViolationException, then loading the string AV's again, etc. Nothing to do with resources. Edit: I've seen this often enough that I almost wonder whether we should special case the resource "Arg_AccessViolationException" here to produce a different message eg "Access violation during resource lookup" which makes things a bit clearer. |
ok, it is only failing that way on the win-arm64 lane, do we think it is a real problem or that we're picking up win-arm64 machines with problems? The same lane is failing on win-x64 with what looks like a timeout but that is happening in main too. |
|
That AV looks like a native compiler upgrade issue... |
so win-arm64 still has issues, are there any other failures unique to this pr? |
lewing
added
the
blocking
|
win-arm64 failures appear to be dotnet/arcade#9284, unrelated to this PR. I don't see anything in the 'runtime' pipeline that I would consider blocking. If the Mono/wasm failures are understood and fixed, IMO this is ready to be merged. |
We're confident that the mono failures seen here aren't blocking or unique to this pr and we have fixes for several of them almost ready |
agocke
approved these changes
May 9, 2022
|
FYI the |
|
Since this toolset update the build output is being aligned and has extra newlines added into it. For instance, when I copy the crossgen invocation that is logged on build I now get Generating native image of System.Private.CoreLib for windows.x64.Checked. Logging to
C:\dev\dotnet\runtime3\dotnet.cmd C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\crossgen2\crossgen2.dll -o:C:\d
ev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\System.Private.CoreLib.dll -r:C:\dev\dotnet\runtime3\artifacts\bin\co
reclr\windows.x64.Checked\IL\*.dll --targetarch:x64 -m:C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\StandardOp
timizationData.mibc --embed-pgo-data -O --verify-type-and-field-layout C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Ch
ecked\IL\System.Private.CoreLib.dll --pdb --pdb-path:C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\PDBinstead of Generating native image of System.Private.CoreLib for windows.x64.Checked. Logging to
C:\dev\dotnet\runtime3\dotnet.cmd C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\crossgen2\crossgen2.dll -o:C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\System.Private.CoreLib.dll -r:C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\IL\*.dll --targetarch:x64 -m:C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\StandardOptimizationData.mibc -m:C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\StandardOptimizationData.mibc -m:C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\StandardOptimizationData.mibc -m:C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\StandardOptimizationData.mibc --embed-pgo-data -O --verify-type-and-field-layout C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\IL\System.Private.CoreLib.dll --pdb --pdb-path:C:\dev\dotnet\runtime3\artifacts\bin\coreclr\windows.x64.Checked\PDBthat is logged before this toolset update. The former cannot be copy pasted cleanly into the terminal, so this is very annoying. Does anyone have any idea why this changed and how we can get back to the previous behavior? |
|
Being unable to copy dumped commandlines and use them without reformatting is slowing down progress. Is there any way to get this fixed? |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request updates the following dependencies
From https://github.com/dotnet/arcade