[manual] Merge release/9.0-staging into release/9.0 #111378
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
Co-authored-by: Tanner Gooding <[email protected]>
…09548) * Fix return address hijacking with CET There is a problematic case when return address is hijacked while in a managed method that tail calls a GC write barrier and when CET is enabled. The write barrier code can change while the handler for the hijacked address is executed from the vectored exception handler. When the vectored exception handler then returns to the write barrier to re-execute the `ret` instruction that has triggered the vectored exception handler due to the main stack containing a different address than the shadow stack (now with the main stack fixed), the instruction may no longer be `ret` due to the change of the write barrier change. This change fixes it by setting the context to return to from the vectored exception handler to point to the caller and setting the Rsp and SSP to match that. That way, the write barrier code no longer matters. * Add equivalent change to nativeaot * Add missing ifdef --------- Co-authored-by: Jan Vorlicek (from Dev Box) <[email protected]>
…net#110163) * Update dependencies from https://github.com/dotnet/emsdk build 20241028.2 (dotnet#109323) Microsoft.SourceBuild.Intermediate.emsdk , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100 , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport From Version 9.0.0-rtm.24519.2 -> To Version 9.0.0-rtm.24528.2 Dependency coherency updates runtime.linux-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-musl-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.win-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.win-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.osx-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.osx-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools From Version 19.1.0-alpha.1.24510.5 -> To Version 19.1.0-alpha.1.24519.2 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> * Update branding to 9.0.1 (dotnet#109563) * Fix FP state restore on macOS exception forwarding The change that enabled AVX512 support in the past has introduced a subtle issue in restoring context for forwarding hardware exceptions that occur in 3rd party non-managed code. In that case, the restored floating point state is garbled. The problem is due to the fact that we pass a x86_avx512_state context to the thread_set_state. That context contains a header field describing the format of the context (it can be AVX, AVX512, 32 or 64 bit, ...). That is then followed by the actual context structure. This style of context is identified e.g. by x86_AVX_STATE flavor. The header field contains the specific flavor, which would be x86_AVX_STATE64 or x86_AVX512_STATE64. The thread_set_state uses the flavor to detect whether the context passed to it is this combined one or just x86_AVX_STATE64 or x86_AVX512_STATE64 which doesn't have the header field. The issue was that while we were passing in the combined context, we were passing in the flavor extracted from its header. So the thread_set_state used the header as part of the context. That resulted e.g. in xmm register contents being shifted by 8 bytes, thus garbling the state. --------- Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: vseanreesermsft <[email protected]> Co-authored-by: Jan Vorlicek <[email protected]>
…#110533) * Fixing step becomes a go * Trying to avoid step that becomes a go * Adding comments and more protections. * fixing comment * Checking if removing this comments, CI failures are gone. * Adding part of the changes to understand the failures on CI * Update src/coreclr/debug/ee/controller.cpp Co-authored-by: mikelle-rogers <[email protected]> * Fixing wrong fix. --------- Co-authored-by: Thays Grazia <[email protected]> Co-authored-by: Thays Grazia <[email protected]> Co-authored-by: mikelle-rogers <[email protected]>
Addressing Tom's and Mikelle's comments Removing unrelated change and adding enum Changing the comment. Co-authored-by: Thays Grazia <[email protected]> Co-authored-by: Thays Grazia <[email protected]>
Co-authored-by: Adeel Mujahid <[email protected]>
…ts with implicit EH control flow (dotnet#109143) Physical promotion sometimes needs to insert read backs of all stale pending replacements when it encounters potential implicit EH control flow (that is, intra-function control flow because of locally caught exceptions). It would be possible for this to interact with QMARKs such that we inserted readbacks inside one of the branches, yet believed we had read back the replacement on all paths. The fix here is to indiscriminately start reading back all replacements before a statement that may cause potential intra-function control flow to occur. Fix dotnet#108969
Co-authored-by: Thays Grazia <[email protected]>
Co-authored-by: Steve Harter <[email protected]>
Co-authored-by: Tim Jones <[email protected]>
Co-authored-by: Matt Thalman <[email protected]>
…rofiling Thread Enumerator (dotnet#110665) * [Profiler] Avoid Recursive ThreadStoreLock Profiling Enumerators look to acquire the ThreadStoreLock. In release config, re-acquiring the ThreadStoreLock and releasing it in ProfilerThreadEnum::Init will cause problems if the callback invoking EnumThread has logic that depends on the ThreadStoreLock being held. To avoid recursively acquiring the ThreadStoreLock, expand the condition when the profiling thread enumerator shouldn't acquire the ThreadStoreLock. * [Profiler] Change order to set fProfilerRequestedRuntimeSuspend There was a potential race condition when setting the flag before suspending and resetting the flag after restarting. For example, if the thread restarting runtime is preempted right after resuming runtime, the flag could remain unset by the time another thread looks to suspend runtime, which would see that the flag as set. * [Profiler][Tests] Add unit test for EnumThreads during suspension * [Profiler][Tests] Fixup EnumThreads test --------- Co-authored-by: mdh1418 <[email protected]>
…` to avoid a JIT crash (dotnet#110568) Because of spurious flow it is possible that the preds of the try-begin block are not the only blocks that can dominate a handler. We handled this possibility, but only for finally/fault blocks that can directly have these edges. However, even other handler blocks can be reachable through spurious paths that involves finally/fault blocks, and in these cases returning the preds of the try-begin block is not enough to compute the right dominator statically.
…ilding WBT (dotnet#110590) * Workaround incorrect mono restore when building WBT * Rollback the workload sdk version
) * Update dependencies from https://github.com/dotnet/sdk build 20241205.31 Microsoft.SourceBuild.Intermediate.sdk , Microsoft.DotNet.ApiCompat.Task From Version 9.0.102-servicing.24579.1 -> To Version 9.0.102-servicing.24605.31 * Update dependencies from https://github.com/dotnet/sdk build 20241210.2 Microsoft.SourceBuild.Intermediate.sdk , Microsoft.DotNet.ApiCompat.Task From Version 9.0.102-servicing.24579.1 -> To Version 9.0.102-servicing.24610.2 * Set UseMonoRuntime=false to workaround WABT restore issue --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Alexander Köplinger <[email protected]>
…10572) * Update dependencies from https://github.com/dotnet/cecil build 20241209.1 Microsoft.SourceBuild.Intermediate.cecil , Microsoft.DotNet.Cecil From Version 0.11.5-alpha.24602.1 -> To Version 0.11.5-alpha.24609.1 * Update dependencies from https://github.com/dotnet/cecil build 20241216.1 Microsoft.SourceBuild.Intermediate.cecil , Microsoft.DotNet.Cecil From Version 0.11.5-alpha.24602.1 -> To Version 0.11.5-alpha.24616.1 * Update dependencies from https://github.com/dotnet/cecil build 20241220.1 Microsoft.SourceBuild.Intermediate.cecil , Microsoft.DotNet.Cecil From Version 0.11.5-alpha.24602.1 -> To Version 0.11.5-alpha.24620.1 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Adeel Mujahid <[email protected]> Co-authored-by: Alexander Köplinger <[email protected]>
Co-authored-by: Tarek Mahmoud Sayed <[email protected]>
…fault `SIGSEGV` handler (dotnet#110863) * Consider SIG_DFL handlers for chaining SIGSEGV signals * cleanup --------- Co-authored-by: Ivan Povazan <[email protected]>
…ence-packages build 20241219.1 (dotnet#110905) Microsoft.SourceBuild.Intermediate.source-build-reference-packages From Version 9.0.0-alpha.1.24568.3 -> To Version 9.0.0-alpha.1.24619.1 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
… handle losing the race for the RCW table (dotnet#111162) Co-authored-by: Sergio Pedri <[email protected]> Co-authored-by: Jeremy Koritzinsky <[email protected]> Co-authored-by: Jeremy Koritzinsky <[email protected]>
…otnet#110764) Co-authored-by: Miha Zupan <[email protected]>
Co-authored-by: Miha Zupan <[email protected]>
…ic code (dotnet#109918) * Fix IDynamicInterfaceCastable with shared generic code Fixes dotnet#72909. Internal team ran into this. Turns out CsWinRT also needs this, but they're were working around instead pushing on a fix. The big problem with this one is that we have an interface call to a default interface method that requires generic context. This means we need some kind of instantiating thunk (since callsite didn't provide generic context because it didn't know it). The normal default interface case uses an instantiating thunk that simply indexes into the interface list of `this`. We know the index of the interface (we don't know the concrete type because `T`s could be involved), but we can easily compute it at runtime from `this`. The problem with `IDynamicInterfaceCastable` is that `this` is useless (the class doesn't know anything about the interface). So we need to get the generic context from somewhere else. In this PR, I'm using the thunkpool as "somewhere else". When we finish interface lookup and find out `IDynamicInterfaceCastable` provided a shared method, we create a thunkpool thunk that stashes away the context. We then call the "default interface method instantiating thunk" and instead of indexing into interface list of `this`, we index into interface list of whatever was stashed away. So there are two thunks before we reach the point of executing the method body. * Finishing touches * Regression test --------- Co-authored-by: Michal Strehovský <[email protected]>
Fixes dotnet#108229. The actual fix is the addition of an `if` check where it originally wasn't. I also fixed the other checks for consistency - positive checks are fine to cache, and negative checks against non-interface targets are also fine to cache. Co-authored-by: Michal Strehovský <[email protected]> Co-authored-by: Jeff Schwartz <[email protected]>
…ssembly (dotnet#110058) * ILC: Allow OOB reference to upgrade framework assembly * Log error for SPC --------- Co-authored-by: Sven Boemer <[email protected]> Co-authored-by: Jeff Schwartz <[email protected]>
* Move ComWrappers AddRef to C/C++ Xaml invokes AddRef while holding a lock that it *also* holds while a GC is in progress. Managed AddRef had to synchronize with the GC that caused intermittent deadlocks with the other thread holding Xaml's lock. This change reverts the managed AddRef implementation to match .NET Native and CoreCLR. Fixes dotnet#110747 * Apply suggestions from code review Co-authored-by: Aaron Robinson <[email protected]> * Update src/coreclr/nativeaot/Runtime/HandleTableHelpers.cpp * Update src/coreclr/nativeaot/Runtime/HandleTableHelpers.cpp * Build break * Update src/coreclr/nativeaot/Runtime/HandleTableHelpers.cpp * Apply suggestions from code review * Update src/coreclr/nativeaot/System.Private.CoreLib/src/System/Runtime/InteropServices/ComWrappers.NativeAot.cs --------- Co-authored-by: Jan Kotas <[email protected]> Co-authored-by: Aaron Robinson <[email protected]> Co-authored-by: Jeff Schwartz <[email protected]>
…om error report (dotnet#111202) * [BrowserDebugProxy] Remove exception details from error report * Update event name --------- Co-authored-by: mdh1418 <[email protected]> Co-authored-by: Jeff Schwartz <[email protected]>
…#111040) * Fix reporting GC fields from base types Fixes dotnet#110836. When we extended managed CorInfoImpl to support object stack allocation in dotnet#104411, there was one more spot that assumed valuetypes only in `GatherClassGCLayout` that we missed. This resulted in not reporting any GC pointers in base types. * Update corinfo.h --------- Co-authored-by: Michal Strehovský <[email protected]>
…ence-packages build 20250110.3 (dotnet#111325) Microsoft.SourceBuild.Intermediate.source-build-reference-packages From Version 9.0.0-alpha.1.24619.1 -> To Version 9.0.0-alpha.1.25060.3 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
) * Update dependencies from https://github.com/dotnet/icu build 20241220.1 Microsoft.NETCore.Runtime.ICU.Transport From Version 9.0.0-rtm.24572.1 -> To Version 9.0.0-rtm.24620.1 * Update dependencies from https://github.com/dotnet/icu build 20241227.2 Microsoft.NETCore.Runtime.ICU.Transport From Version 9.0.0-rtm.24572.1 -> To Version 9.0.0-rtm.24627.2 * Update dependencies from https://github.com/dotnet/icu build 20250107.1 Microsoft.NETCore.Runtime.ICU.Transport From Version 9.0.0-rtm.24572.1 -> To Version 9.0.0-rtm.25057.1 * Update dependencies from https://github.com/dotnet/icu build 20250108.1 Microsoft.NETCore.Runtime.ICU.Transport From Version 9.0.0-rtm.24572.1 -> To Version 9.0.0-rtm.25058.1 * Update dependencies from https://github.com/dotnet/icu build 20250111.1 Microsoft.NETCore.Runtime.ICU.Transport From Version 9.0.0-rtm.24572.1 -> To Version 9.0.0-rtm.25061.1 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…10970) * Update dependencies from https://github.com/dotnet/emsdk build 20241227.3 Microsoft.SourceBuild.Intermediate.emsdk , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100 , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport From Version 9.0.1-servicing.24571.2 -> To Version 9.0.1-servicing.24627.3 Dependency coherency updates runtime.linux-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-musl-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.win-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.win-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.osx-arm64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.osx-x64.Microsoft.NETCore.Runtime.JIT.Tools,runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools,runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk,runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools From Version 19.1.0-alpha.1.24554.4 -> To Version 19.1.0-alpha.1.24575.1 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport * Update dependencies from https://github.com/dotnet/emsdk build 20250107.2 Microsoft.SourceBuild.Intermediate.emsdk , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100 , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport From Version 9.0.1-servicing.24571.2 -> To Version 9.0.1-servicing.25057.2 * Update dependencies from https://github.com/dotnet/emsdk build 20250108.2 Microsoft.SourceBuild.Intermediate.emsdk , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100 , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport From Version 9.0.1-servicing.24571.2 -> To Version 9.0.2-servicing.25058.2 * Update dependencies from https://github.com/dotnet/emsdk build 20250111.2 Microsoft.SourceBuild.Intermediate.emsdk , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100 , Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport From Version 9.0.1-servicing.24571.2 -> To Version 9.0.2-servicing.25061.2 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…10937) * Update dependencies from https://github.com/dotnet/cecil build 20241222.3 Microsoft.SourceBuild.Intermediate.cecil , Microsoft.DotNet.Cecil From Version 0.11.5-alpha.24620.1 -> To Version 0.11.5-alpha.24622.3 * Update dependencies from https://github.com/dotnet/cecil build 20250106.3 Microsoft.SourceBuild.Intermediate.cecil , Microsoft.DotNet.Cecil From Version 0.11.5-alpha.24620.1 -> To Version 0.11.5-alpha.25056.3 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…111017) * Update dependencies from https://github.com/dotnet/arcade build 20241223.3 Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.GenAPI , Microsoft.DotNet.GenFacades , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.XliffTasks , Microsoft.DotNet.XUnitAssert , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.XUnitExtensions From Version 9.0.0-beta.24572.2 -> To Version 9.0.0-beta.24623.3 * Update dependencies from https://github.com/dotnet/arcade build 20250108.5 Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.GenAPI , Microsoft.DotNet.GenFacades , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.XliffTasks , Microsoft.DotNet.XUnitAssert , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.XUnitExtensions From Version 9.0.0-beta.24572.2 -> To Version 9.0.0-beta.25058.5 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…dotnet#110936) * Update dependencies from https://github.com/dotnet/hotreload-utils build 20241224.2 Microsoft.DotNet.HotReload.Utils.Generator.BuildTool From Version 9.0.0-alpha.0.24561.2 -> To Version 9.0.0-alpha.0.24624.2 * Update dependencies from https://github.com/dotnet/hotreload-utils build 20250107.3 Microsoft.DotNet.HotReload.Utils.Generator.BuildTool From Version 9.0.0-alpha.0.24561.2 -> To Version 9.0.0-alpha.0.25057.3 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Carlos Sánchez López <[email protected]>
…ETHOD Re-try loading ENGINE keys with a non-NULL UI_METHOD Co-authored-by: Kevin Jones <[email protected]>
When AsnDecoder.ReadEncodedValue is used on a payload where the encoded length plus the number of bytes representing the encoded length plus the number of bytes representing the tag exceeds int.MaxValue it erroneously reports success. Every known caller of this method immediately follows it with a call to a Span or Memory .Slice, which results in an ArgumentException that the requested length exceeds the number of bytes available in the buffer. Because AsnDecoder was extracted out of AsnReader, most AsnDecoder tests are done indirectly as AsnReader tests, or are done in the same test class that tests the related functionality on AsnReader. Since there's not a clear analogue for ReadEncodedValue (that does not immediately Slice), this change introduces a new subtree for AsnDecoder tests, only populating it with (Try)ReadEncodedValue tests. It also adds "large length" tests for ReadSetOf and ReadSequence, for good measure. Co-authored-by: Jeremy Barton <[email protected]>
carlossanlop
added
Servicing-approved
carlossanlop
requested review from
marek-safar,
sbomer,
akoeplinger,
maraf,
ilonatommy,
thaystg,
lewing,
pavelsavara,
BrzVlad,
lambdageek,
steveisok and
MichalStrehovsky
as code owners
This was referenced Jan 14, 2025
Open
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.
MERGE COMMIT!
Excluded from this PR:
Since they're not yet Tactics approved, we'll have to flow them manually from staging to base early morning tomorrow.