* Add repro.

* fix the issue.

* delete a dead condition

* add a todo.

* Fix the failures.

Change interface map layout in two interesting ways
1. For interface maps defined in System.Private.CoreLib, rely on the C# compiler to prevent any ambiguous duplicates, and to find the full interface expansion, instead of expanding it within the type loader See code marked with #SpecialCorelibInterfaceExpansionAlgorithm
- Note that this optimization is only applied for ValueTypes as the presence of inheritance makes the optimization much more complex in many cases, and isn't needed.
- This optimization reduces the amount of parsing of the interface implementation table must be done for valuetypes in CoreLib. In particular, with the new interfaces that are added as part of #54650 there is a very deep interface hierarchy that requires a great deal of scanning. As those interfaces are added to all the primitive types, the impact on startup performance is significant and measurable.
2. For interface map expansion that follows the curiously recurring generic pattern, place the open instantiation of the type in the interface map instead of the the exact instantiation, and update all places in the runtime which consider the interface map to deal with that change (Mostly by adding special purpose logic to work with the special marker type in the interface map, but there is also logic to simply force the exact interface type to be loaded, when working with the partially loaded type is not quite good enough, or excessively complex)
- This optimization reduces the set of interface types that need to be loaded if they are unused. Of particular benefit are the numerous interfaces associated with the primitive types that are added as part of #54650.

Performance of launching an extremely simple .NET process (process with empty main method). Results acquired using local testing on my developer machine, using a simple script that launches the process 500 times in a row.

| Before #54650 | After #54650 | After #54650 and #54588 (this pr) |
| :-: | :-: | :-: |
| 14.1ms | 16.5ms |14.3ms |

* Use string constructor that takes length instead of the one that searches for a null terminator.

Fixes #54662

* Marshal back buffer size or string to first null terminator, whichever is shorter

* Add tests.

* Add unicode test.

* Use the same implementation style for the wstr case case as the cstr case

* Fix accidental deletion from test.

The two properties got different diagnostic IDs so that the messages could better reflect the caller recovery action.

* First round of converting System.Drawing.Common to COMWrappers

Using COM Wrappers makes the library trim compatible.

* Add Trimming Test for Icon.Save

* Add support for OS specific trimming tests

* Use function pointers instead of delegates
* Rename Guid to IID
* Better interop to closely match the native side
* Release any COM pointer that was QueryInterface
* Use pointers instead of Marshal.PtrToStructure/StructureToPtr
* No need for a VTable struct, just set each function pointer right into the table
* Wrap all managed calls in try-catch and return HResult
* Use COM naming
* Fix method signature to use pointer instead of out.
* CheckStatus => ThrowExceptionForHR

* Pass -1 to Marshal.GetExceptionForHR so it doesn't query GetErrorInfo, and always returns the correct exception type
* Create the PictureWrapper with UniqueInstance, so it doesn't get cached. Caching it causes lifetime issues.

This change adds SymmetricAlgorithm.EncryptEcb, SymmetricAlgorithm.DecryptEcb, their
respective Try- and -Core methods, derived type implementations thereof, and tests.

There's an open question of should these members on on the base class throw or
"succeed if the Mode property is in agreement with the algorithm".  While the latter is "nicer",
just throwing  is easier to reason about, and that's the current behavior.
Co-authored-by: NJeremy Barton <jbarton@microsoft.com>

- added TargetFrameworkForNETCoreTasks property similar to NetCoreAppToolCurrent one as NetCoreAppToolCurrent will likely bump more aggressively between new sdks;  
- renamed TargetFrameworkForNETFramework to TargetFrameworkForNETFrameworkTasks.

The condition on the import group for the iOS and tvOS simulators was not valid since iOS/tvOSSimulator is not a `TargetPlatformIdentifier`. To simplify, the simulator imports were moved under iOS/tvOS.

Fixes https://github.com/dotnet/runtime/issues/53427Co-authored-by: NSteve Pfister <steve.pfister@microsoft.com>

Avoid passing the array by ref and yielding inside the loop, which defeat various optimizations (e.g. bounds checking elimination).

* [mono][debugger] Fixing side effect of #48483

When starting XAML Hot Reload, in transform.c the seq_point was saved using jit_mm_for_method: https://github.com/thaystg/runtime/blob/abccfadbf570033efee8ac9a6992f6f7ee51f474/src/mono/mono/mini/interp/transform.c#L9760
When trying to search was trying on get_default_jit_mm.

* Fixing everywhere that uses seq_points.

* Not used.

* Revert "Not used."

This reverts commit fd7f2061b40436300abdcc919705b56af53f4ca0.

* Revert "Fixing everywhere that uses seq_points."

This reverts commit 6faffb8c92a1c9be17d8c53d5f735075b9212220.

* Revert "[mono][debugger] Fixing side effect of #48483"

This reverts commit 44601d310bd5ca1929604af5e0b96436b416ced8.

* Always use get_default_jit_mm for seq_points.

* Adding a test case and fixing wasm debugging on ALC.

* Moving implementation to avoid changing line number

* Update src/mono/wasm/debugger/DebuggerTestSuite/Tests.cs
Co-authored-by: NLarry Ewing <lewing@microsoft.com>

* Update src/mono/wasm/debugger/DebuggerTestSuite/Tests.cs
Co-authored-by: NLarry Ewing <lewing@microsoft.com>
Co-authored-by: NLarry Ewing <lewing@microsoft.com>

It can easily use a static singleton, as the instance is immutable and exists purely to provide a "I don't have line info" / (0,0) value if anyone queries for position.

This is needed because, when inlining op_Inequality, the information on whether the arguments are runtime types gets lost. We should track that information instead when inlining, but it is a more invasive change.

* Fix missing entrypoints and add build-time validation

* Fix missing include

* Update src/libraries/Native/Unix/System.Security.Cryptography.Native.Apple/CMakeLists.txt
Co-authored-by: NJan Kotas <jkotas@microsoft.com>

Do not timeout waiting for the host to start when running with
the debugger attached.

Addresses dotnet/aspnetcore#33886.

* Fix MacOS build on 11.x SDK and Catalyst build

The configure.cmake was not getting the minimum supported OS version because
it was being set via set_compile_options and the config functions can only
get options from CMAKE_XXX_FLAGS.

* Add comment explaining why we set the macOS options via CMAKE_XXX_FLAGS

* Move DependentHandle to System.Runtime

* Update DependentHandle APIs to follow review

* Make DependentHandle type public

* Update DependentHandle on Mono runtime

* Add allocation checks to DependentHandle APIs

This avoids throwing ExecutionEngineException-s if one of the public APIs is called on a non-allocated DependentHandle instance

* Add more unit tests for new public DependentHandle APIs

* Add faster, unsafe internal APIs versions to DependentHandle

* Naming improvements to Ephemeron type

The ephemeron type is checked in the Mono runtime in "object.c" as follows:

m_class_get_image (klass) == mono_defaults.corlib && !strcmp ("Ephemeron", m_class_get_name (klass))

As such, the namespace it belongs to in the managed runtime doesn't matter: the VM will just check
that the type name matches, and that the type is in fact defined in corelib. This means we can
just move it to System.Runtime without worrying about it being properly managed in the VM.
Additionally, the type is defined in "sgen-mono.c" as follows:

typedef struct {
    GCObject* key;
    GCObject* value;
} Ephemeron;

So as long as the layout matches the one of the type defined in C# (which it does), we're also free
to rename the fields to better follow the naming guidelines, and the VM will have no issues with it.

* Code style tweaks, improved nullability annotations

* Remove incorrect DependentHandle comment on Mono

* Add default Dispose test for DependentHandle
Co-authored-by: NStephen Toub <stoub@microsoft.com>

* Fix race condition in DependentHandle on Mono

* Optimize DependentHandle.nGetPrimary on CoreCLR

Removed internal call, same optimization as GCHandle

* Small IL codegen improvement in DependentHandle.nGetPrimary

* Simplify comments, add #ifdef for using directive

* Minor code style tweaks

* Change nGetPrimaryAndSecondary to nGetSecondary

* Minor code refactoring to DependentHandle on Mono

* Rename DependentHandle FCalls

* Remove DependentHandle.UnsafeGetTargetAndDependent

* Remove DependentHandle.GetTargetAndDependent

* Fix FCall path for internal DependentHandle APIs

* Add more DependentHandle unit tests

* Reintroduce DependentHandle.GetTargetAndDependent()

This fixes a bug due to a race condition in ConditionalWeakTable<K, V>, which relies on this method which atomically retrieves both target and dependent with respect to target being set to null concurrently by other threads. This also exposes the same API publically to allow consumers to potentially implement custom conditional weak tables in the same manner.

* Minor IL tweaks to produce smaller IR in the JIT

* Add DependentHandle.StopTracking() API

This also fixes two potential GC holes when setting DependentHandle.Target (see conversation from https://github.com/dotnet/runtime/pull/54246#issuecomment-863285327 onwards)

* Rename InternalSetTarget to StopTracking, remove redundant param

* Remove FCUnique from InternalStopTracking

This was added in https://github.com/dotnet/runtime/pull/39810 to avoid a collision with MarshalNative::GCHandleInternalSet, as the two FCalls had identical implementations and their entry points were not unique. This should no longer be needed after 099fc478551f46cc54e7a18a32d9a9ac73727c73, as that changed both the signature and the implementation of this FCall.

* Update API surface to match approved specs from API review

* Update DependentHandle XML docs
Co-authored-by: NStephen Toub <stoub@microsoft.com>

* add more tests

* StreamWriter and StreamReader require FileStreamOptions with necessary access

* allow for bufferSize == 0

* extend the test

* refactor the tests

* Revert "allow for bufferSize == 0"

This reverts commit f1259be18a3446c1b8939883f484cc28347c74cf.

There's a race condition in the test between the timer firing and cancellation being requested.  It repros more on Linux because there's a smaller quantum on Linux than on Windows.

* expose unix file descriptor safe memory map

* store handle after DangerousAddRef

* add test verifying handle matches filestream handle

* Update src/libraries/System.IO.MemoryMappedFiles/src/Microsoft/Win32/SafeMemoryMappedFileHandle.Unix.cs
Co-authored-by: NStephen Toub <stoub@microsoft.com>

* Update src/libraries/System.IO.MemoryMappedFiles/src/Microsoft/Win32/SafeMemoryMappedFileHandle.Unix.cs
Co-authored-by: NStephen Toub <stoub@microsoft.com>

* Update src/libraries/System.IO.MemoryMappedFiles/src/Microsoft/Win32/SafeMemoryMappedFileHandle.Unix.cs
Co-authored-by: NStephen Toub <stoub@microsoft.com>

* Update src/libraries/System.IO.MemoryMappedFiles/src/Microsoft/Win32/SafeMemoryMappedFileHandle.Unix.cs
Co-authored-by: NStephen Toub <stoub@microsoft.com>

* Update src/libraries/System.IO.MemoryMappedFiles/tests/MemoryMappedFile.CreateFromFile.Tests.cs
Co-authored-by: NStephen Toub <stoub@microsoft.com>

* Dispose MemoryMappedFile in MapHandleMatchesFileStreamHandle test

* Update src/libraries/System.IO.MemoryMappedFiles/src/Microsoft/Win32/SafeMemoryMappedFileHandle.Unix.cs
Co-authored-by: NStephen Toub <stoub@microsoft.com>

* Update MemoryMappedFile.CreateFromFile.Tests.cs

* Move mmf in test to using block

* Fix test
Co-authored-by: NDanny Friar <danny@Dannys-MacBook-Pro.local>
Co-authored-by: NStephen Toub <stoub@microsoft.com>

add pre-cancellation check and enable ReadWriteAsync_PrecanceledOperations_ThrowsCancellationException for QUIC (#54540)

Via unsafe code, getting the lower Vector128 from a Vector256 ends up as a move of `sizeof (Vector128)` from a Vector256 var. However, the destination var is not a valid copy of the source var, having a different type

This reverts commit b2fe6678.

* Add metadatatoken override to SymbolMethod

* Add test
Co-authored-by: NJan Kotas <jkotas@microsoft.com>

* Rewrite fgMorph(Copy/Init)Block.

* fix a last squash error.

* fix nits

- Remove empty CreateInstanceCallSite file
- Removed ServiceScopeFactoryCallsite and used ConstantCallsite instead.
- Added fast path if the value is already cached on the callsite.