* samples for ES6 and CJS
* hack for in-tree linking
* binlog for samples

* Expose AppContext.SetData in ref assembly

* Implement test for Set/GetData

* Add doc comment

* Implementing support on running getters using Runtime.GetProperties as it's done by chrome.

* Addressing @radical comments.

* testing datetime

The package we're currently using is missing https://github.com/dotnet/runtimelab/pull/1519.

Android puts pthread stuff into libc. Because this wasn't detected, we are using some iOS fallbacks in System.Native. I'm propagating how pthreads are detected in the CoreCLR PAL (that was fixed up for Android in the CoreCLR PAL a couple years ago).

Failure to properly detect it here was causing build breaks in CoreCLR on Android (that's how I found this).

* [mono] Add a mono_dummy_jit_icall_val () icall.

This can be used to trace values from AOT code during runtime
debugging.

* [mono] Avoid adding a try clause to vector alloc wrappers.

Previously, a try-catch clause was added to the vector Alloc
wrappers to convert the OverflowException thrown by the .ovf
opcodes to an OutOfMemoryException. This could cause EH problems on wasm
since on wasm no AOTed code should contain clauses, but this
wrapper was still AOTed for performance reasons.
Instead, add a new CIL opcode to make the .ovf opcodes throw the
OutOfMemoryException directly.

* Disable inline rgctx fetch in mono_decompose_vtype_opts () as well.

It can't handle the new bblocks added by the inline rgctx fetch code.

* [mono] Factor out the slow path of Array.Copy () into a separate method.

The slowpath contained a try-catch clause, preventing Array.Copy () from
being AOTed on WASM.

* [mono] Fix assigning a name to LLVM Alloca instructions.

* Add a V=1 makefile option to wasm/Makefile.

* Add a WasmAotProfilePath build property.

Co-authored-by: Ndotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

By it's default behavior, WinHttp stops reading the stream when Content-Length is specified, this prevents us to read the remaining trailers. Opt-in into WINHTTP_OPTION_REQUIRE_STREAM_END, so WinHttpHandler reads HTTP2 streams to the end regardless of Content-Length.

Co-authored-by: Ndotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

Corrected return value type in XML documentation.

Fix #62993
Co-authored-by: NBjörn Sjögren <bjs@hms.se>

Co-authored-by: Ndotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

* Have NativeAOT test execution project include SDK

The SDK contains logic to configure trimming - we were skipping all of that. We couldn't previously include the SDK because it would reflection-root the entrypoint assembly. No longer the case after #62890.

Change encodes 'w' and 's' in the insFlags struct and INS_FLAG
entry for xarch instruction table. In addition, add methods to check
check if this flag is set for an instruction, which allows to start
simplifying some of the various ad-hoc checks for these bits that were
previously done per-instruction throughout emitxarch.cpp.

* enable testing with NodeJS on CI
* Fix task marshal tests.
Co-authored-by: NMarek Fišera <mara@neptuo.com>

* Suppress OSR for crossgen2 execution

In CI testing, crossgen2 currently is run via a .NET 6 runtime, and
that runtime has some bugs in OSR.

Work around by suppressing OSR for the duration of the run. We should
be able to revert this once we update the crossgen2 runtime
to a .NET 7 version.

* add COMPlus exclusions for readytorun/multifolder

To make sure ApiCompat tooling for NativeAOT's CoreLib runs at least in some legs, compile libs against NativeAOT CoreLib if we're building CLR, but not building the JIT flavor of the runtime.

The baselining is necessary because the reflection stack of NativeAOT doesn't live in CoreLib.

The CannotRemoveBaseTypeOrInteface baselining will go away once https://github.com/dotnet/runtime/issues/62944 gets fixed. It's one of the "overall goodness" things we can take out of NativeAOT and put it into all runtimes.

This is now getting hit in #62927, so it's somewhat more urgent. (The feature switches from the SDK put us into the situation that triggers this bug around `RunClassConstructor` on an otherwise unused type.)

Fixes dotnet/runtimelab#987.

Remember what class constructor contexts we saw during scanning phase and if the owning type is also generated, assume `RunClassConstructor` could be used and ensure the cctor context is also generated in the compilation phase.

This is somewhat less precise, but introducing a new node type for "a type used with `RunClassConstructor`" that dataflow analysis could report doesn't seem worth it.

String constructors implementation methods had a dummy this argument on CoreCLR, but not on other runtimes.  It required ifdefs in the implementation. This change removes the ifdefs and makes the string constructors implementation methods uniform accross all runtimes. It is possible to do this cleanup now since we have just bumped R2R version band.

This test set contains several project groups exercising various
primitive types using explicit and sequential layout. Each group
comprises a variant source file implementing a sequential or
explicit struct / class 'AA' with a field of the given type
(e.g. expl_byte_1.cs / seq_byte_1.cs) and a common source file
(body_byte.cs in this case) implementing a number of tests
manipulating the type 'AA' that is shared by the explicit and
the sequential variant of the project (e.q. expl_byte_1[_d/_r].csproj,
seq_byte_1[_d/_r].csproj).

The problem was that the Main method resided in the common source
file so that it was always present twice - once for the sequential
and once for the explicit variant of the test (ignoring the _d / _r
flavors). After experimenting with several ways to refactor the tests
I have come to the conclusion that the most straightforward way
of deduplicating them is just moving the Main method out of the shared
source code into the variant (explicit / sequential) sources that
aren't shared.

Thanks

Tomas

* Introduce IsNeverNegative

* Address feedback

* Apply suggestions from code review
Co-authored-by: NSingleAccretion <62474226+SingleAccretion@users.noreply.github.com>

* Address feedback

* fix build on x86
Co-authored-by: NSingleAccretion <62474226+SingleAccretion@users.noreply.github.com>

Co-authored-by: Ndotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

* OSR support for Arm64

Enable OSR for Arm64:
* rename `FpToSpDelta` in `PatchpointInfo` to `TotalFrameSize` so it makes
sense for both x64 and Arm64.
* make it clear that the local offsets in `PatchpointInfo` are virtual
(relative to the top of the frame). Adjust recorded Arm64 offsets to match.
* add new jit config setting `JitEnableOSRRange` to allow selectively enabling
OSR for only a subset of jitted methods.
* Arm64 OSR method is passed Tier0 SP but not Tier0 FP, as Tier0 FP can point
either at top or bottom of Tier0 frame depending on frame type. For Arm64 the
OSR method establishes its own FP that chains to caller FP. (I will likely
revise x64 to work this way too, as it makes simple FP chain stackwalks work
out better).
* The Arm64 OSR epilog gets an extra SP adjustment to remove the Tier0 frame.
* The Arm64 OSR prolog gets a phantom SP adjustment in unwind to account for
being passed the Tier0 SP.
* pad OSR funclet frames with tier0 frame size so `PSPSym` ends up at the same
caller-SP relative offset as the OSR frame
* handle the large `fiSpDelta1` offsets from the funclet frame padding 
* local/arg init for the OSR frame from the Tier0 frame was moved into a new
method `genEnregisterOSRArgsAndLocals`; implemented the ARM64 version.
* sequencing of this initialization in the prolog reordered slightly to prevent
inadvertent clobbering.
* comments/code that referred to `original` or `old` method were revised to
instead try and consistently use `tier0`.
* support the mixed-altjit case for OSR by allocating a local copy of the
patchpoint info with similar and plausible information.
* add symbol table note for locals in OSR methods that live on the Tier0 frame.
* fix `fgIsThrowHlpBlk` when called on an empty block
* broaden the jit-experimental testing matrix to include Arm64.

Disable some suspicious tests which might lead to OOM crashes on Android emulators and arm64 devices (#62767)

Just blindly disabling several crypto tests near which crashes have been observed for a while (based on a couple of the mobile targets rolling build runs). 

Disabled tests:

- System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.ReadWriteDiminishedDPPrivatePkcs1
- System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.ReadEncryptedDiminishedDP_EmptyPassword
- System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.DecryptPkcs12PbeTooManyIterations
- System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.ReadWriteRsa2048EncryptedPkcs8_Pbes2HighIterations
- System.Security.Cryptography.Dsa.Tests.DSAKeyFileTests.cs.DecryptPkcs12PbeTooManyIterations
- System.Security.Cryptography.Dsa.TestsDSAKeyFileTests.cs.ReadWriteDsa1024EncryptedPkcs8_Pbes2HighIterations
- System.Security.Cryptography.Tests.ECKeyFileTests.DecryptPkcs12PbeTooManyIterations
- System.Security.Cryptography.Tests.ECKeyFileTests.ReadWriteEc256EncryptedPkcs8_Pbes2HighIterations
- System.Security.Cryptography.EcDsa.Tests.ECDsaTests_Span


See also https://github.com/dotnet/runtime/issues/62547.

Iteration count was dropped to a smaller number in https://github.com/dotnet/corert/pull/2867. Looks like it's not enough because we see this test fail in the CI.

Every unwind fragment should be non-zero sized. If we consider
splitting on a boundary that would create a zero-sized fragment,
don't report that one. This only occurs when setting the
stress mode JitSplitFunctionSize to something small.

* Fix duplicated FldSeq in block morphing

Reusing the address for the first field is problematic as
the first field is likely to be at a zero offset, thus a
zero-offset field sequence will be attached to it, and
subsequent copies of the same tree will pick it up, which
is incorrect.

Fix by reusing the address for the last field instead.

* Add a test

* Add a description of the issue to the test