[release/10.0.1xx-rc1] Adding the vector constants property extensions that are only supported for certain T #2016
Conversation
|
@dotnet/source-build, there's some unexpected failures here that look like an older version of Roslyn is being used than expected. Will this require the toolset to be rebootsrapped? For reference, the failure is indicating The Roslyn update taken 7 hours ago (#1962) has this and some other relevant changes (older Roslyn changes also have most of the necessary changes, but would have failed on the type forwards instead) |
|
Inside the VMR the compiler is always used from the toolset SDK (not the OOB package). Yes, sounds like we would need a re-bootstrap. |
Do I need to log an issue or anything to track that? It sounds like it would be needed for the PR going into dotnet/runtime main as well (dotnet/runtime#117975) |
jeffhandley
left a comment
There was a problem hiding this comment.
This was approved for inclusion in .NET 10 RC1
|
Re-bootstrapping is documented here: https://github.com/dotnet/source-build/blob/main/Documentation/VMR-re-bootstrapping.md#automated I can help with the re-bootstrap process: #2037 @tannergooding I also see PackageValidation failures in this PR |
…s that are only supported for certain T (dotnet#2016) Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
Backport of dotnet/runtime#117975
Description
When the end-to-end extension operator support landed last week, we were able to Expose the extension operators for Tensor, TensorSpan, and ROTensorSpan (dotnet/runtime#117997) and get that merged in for RC1 ahead of the snap. We also had a scenario for using extension operators on Vector that got blocked by Roslyn hits "unreachable" exception when processing type forward to a class containing an extension group (dotnet/roslyn#79894).
That issue was fixed in Unblock type forwarding scenarios involving extensions (dotnet/roslyn#79905), which is already flowing into RC1 as part of [release/10.0.1xx-rc1] Source code updates from dotnet/roslyn (dotnet/dotnet#1962). The dotnet/runtime#117975 PR consumes that fix to gain extension operator support on Vector.
We are requesting to backport the Vector usage of extension operators into RC1 alongside Roslyn’s fix for the scenario.
Customer Impact
Merging this integration will allow Libraries customers to exercise these new Vector APIs in RC1 alongside the Tensor APIs also included in the release. This grants us more opportunity to receive feedback from customers on the end-to-end for the new language feature and the libraries usage.
Risk
Medium. The previous attempt to merge this integration had failures that prevented the merge. By merging the integration directly into dotnet/dotnet, only a subset of the tests will be run there with the remainder of the validation running once the code flows into dotnet/runtime. This is a risk trade-off that utilizes the VMR to shorten the time it takes to achieve the backport, keeping RC1 on schedule.
The risk is mitigated by ensuring Adding the vector constants property extensions that are only supported for certain T (dotnet/runtime#117975) is fully validated in main. We will wait to create the backport PR until the merge into main is completed. Once the backport PR is created and merged, we will continue to monitor the code flow PRs closely. If any issues are detected when the code flows from dotnet/dotnet into dotnet/runtime’s release/10.0-rc1 branch, the crew is ready to react immediately.
Should any issues arise at that time, we would have the options of: