* Move CancellationToken throwing logic to the end of `Task.Wait`

To match the default behavior

* Fix timeout behavior in `NetworkStream.Close`

Use milliseconds instead of seconds

* Remove `SendPingAsync` overloads

* Annotate things

* InnerHandler not null

* Fix build

They were disabled already so were behaving as no-ops.
The recommended replacement is using EventCounters.

Fixes NativeAOT Pri-0 test baselines.

Add log to file option to createdump

Add DOTNET_CreateDumpVerboseDiagnostics env var

Make the timestamp ms and 8 hex digits

Add printf_status and printf_error that all stdout goes through.

Prefix "[createdump" to all printf_status/error output.

Requires a JitInterface change because we need to be able to pass information about constraints to `getReadyToRunDelegateCtorHelper`

Make this a property of the local, in anticipation of needing to check this in
cases where we won't have access to the compiler object.

Unify marking of OSR exposed locals.

* Run audit fix by default

* Run update before audit

* review suggestions

* Revert "Workaround to remove unnecessary bounds checks when using {ReadOnly}Span.IsEmpty (dotnet/coreclr#19640)"

This reverts commit 82bd67f7.

* Update doc comments

* Apply suggestions from code review
Co-authored-by: NRobin Lindner <robin.lindner1@t-online.de>

* Apply suggestions from code review
Co-authored-by: NRobin Lindner <robin@deeprobin.de>
Co-authored-by: NAaron Robinson <arobins@microsoft.com>
Co-authored-by: NRobin Lindner <robin.lindner1@t-online.de>
Co-authored-by: NRobin Lindner <robin@deeprobin.de>

`GetModuleForSimpleName` checks that the assembly name matches the file name we just opened and throws if it doesn't. Avoid this API for the `--root` command line argument.

This is needed because we have 400+ Pri-0 tests in IL where the assembly name doesn't match the file name of the test.

Perform type/layout verification on some mono-config elements to avoid silent failures or crashes later (#65449)

Perform type/layout verification on some mono-config elements to avoid silent failures or crashes later

* Add documentation on GT_CAST's semantics

The semantics of cast nodes are notoriously complicated.
It was requested documentation be added clarifying some
of the less obvious bits, this change does just that.

* Fix a typo, add the "integer -> FP" case

"Integer -> FP" (always) unchecked casts also use "IsUnsigned".

* Issue at most one connection attempt per request

* Drop the Try- from PeekNextRequestForConnectionAttempt

* Add test

* PR feedback

* Entry => QueueItem

Also, shorten struct type name display. Use the `appendClassName`
API to construct a smaller class name, without the full assembly info.

* [wasm] Mark result as Error if it has 'exceptionDetails' field

* [wasm] Don't swallow errors from methods that enumerate properties

.. like for getting locals. Instead, surface the original errors which
have details of the actual failure, to the point before we send a
response.

This helps debugging a lot, so instead of `Unable to evaluate dotnet:scope:1`,
we get more detailed errors.

* [wasm] Throw an exception when a debugger agent command fails

We are checking `HasError` property on the binary reader in very few
places. Other places just try to use the reader which then fails with
errors in reading, or base64 conversion etc, and we don't get any info
about what command failed.

Instead, throw an exception on error by default. But the existing
locations that do check `HasError`, don't throw for them.

* [wasm] Fix evaluating expression calling a non-existant method

Issue: https://github.com/dotnet/runtime/issues/65744

The test doesn't fail because it is expecting an error, and it gets
that.

But the log shows an assertion:

`console.error: * Assertion at /workspaces/runtime/src/mono/mono/metadata/class-accessors.c:71, condition `<disabled>' not met`

1. This is because the debugger-agent does not check that the `klass`
argument is NULL, which is fixed by adding that check.

2. But the reason why this got called with `klass==NULL`, is because
`MemberReferenceResolver.Resolve` tries first to find the non-existant
method on the type itself. Then it tries to find the method on
`System.Linq.Enumerable`, but fails to find a typeid for that.
  - but continues to send a command to get the methods on that
  `linqTypeId==0`.

* [wasm] Add some missing exception logging in the proxy

* cleaup

* [wasm] GetMethodIdByName: throw on invalid type ids

* [wasm] Improve error handling in expression evaluation

* Cleanup

* Disable failing test - https://github.com/dotnet/runtime/issues/65881

* Add missed files

* Address @ilonatommy's feedback

* Bump emscripten to 3.1.7

* Use new docker images with emscripten 3.1.7

* Update exported functions list for 3.1.7:

* Use 3.1.7 emsdk and icu packages
Co-authored-by: NAnkit Jain <radical@gmail.com>

* Update dependencies from https://github.com/dotnet/roslyn-analyzers build 20220324.1

Microsoft.CodeAnalysis.NetAnalyzers
 From Version 7.0.0-preview1.22166.1 -> To Version 7.0.0-preview1.22174.1

* React to DisableRuntimeMarshalling attribute analyzer by switching a few extraneous places to source-generated marshalling and removing some unused attributes.
Co-authored-by: Ndotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: NJeremy Koritzinsky <jkoritzinsky@gmail.com>

* Publish the maui iOS Podcast app in the build yml
* Pipe the built Podcast IPA file through and test it.

Co-authored-by: Ncarlossanlop <carlossanlop@users.noreply.github.com>

Co-authored-by: NJeremy Barton <jbarton@microsoft.com>

.. inspired by https://github.com/dotnet/runtime/issues/66149 .

* [wasm] EmccCompile: Improve AOT time by better utilizing the cores

Problem:

`EmccCompile` tasks compiles `.bc` files to `.o` files, and uses
`Parallel.ForEach` to run `emcc` for these in parallel.

The problem manifests when `EmccCompile` is compiling lot of files.
- To start with, the intended number of cores are being used
- but at some point (in my case after ~150 out of 180 files), the number
  of cores being utilized goes down to 1.
- And the reason is that `Parallel.ForEach` partitions the list of
  files(jobs), and they execute only the assigned jobs

From: https://github.com/dotnet/runtime/issues/46146#issuecomment-754021690

Stephen Toub:
    "As such, by default ForEach works on a scheme whereby each
    thread takes one item each time it goes back to the enumerator,
    and then after a few times of this upgrades to taking two items
    each time it goes back to the enumerator, and then four, and
    then eight, and so on. This ammortizes the cost of taking and
    releasing the lock across multiple items, while still enabling
    parallelization for enumerables containing just a few items. It
    does, however, mean that if you've got a case where the body
    takes a really long time and the work for every item is
    heterogeneous, you can end up with an imbalance."

The above means that with wildy different times taken by each job, we
can end up in this imbalance, leading to some cores being idle, which
others get reduced to running jobs sequentially.

Instead, we want to use work-stealing so jobs can be run by any partition.

In my highly unscientific testing, with AOT for `System.Buffers.Tests`,
the total time to run `EmccCompile` for 181 assemblies goes from 5.7mins
to 4.0mins .

* MonoAOTCompiler.cs: Ensure that the parallel jobs get scheduled with

.. work-stealing, instead of being partitioned.

Added --logbuildoutput to microbenchmark runs.

After merging in the last preparatory change (deduplication of
tests with the same assembly names) I'm now testing the "final"
JIT/Methodical switchover change; this testing uncovered a few
previously unseen issues related to the merged wrappers and I'm
sending them for a separate PR to decouple them from the big
mechanical switchover change.

1) For out-of-process tests, "Method" contains the relative test
execution script path; we need to prefix the string with "@"
to avoid complaining about backslashes on Windows.

2) Jeremy recently added a consistency check to catch multiple
projects producing assemblies with the same simple name; turns
out there was a subtle bug where the check blew up on projects
with DisableProjectBuild set to true.

3) A similar problem exists for projects with the property
CLRTestTargetUnsupported but I haven't added it to the fix;
I believe it is healthy to receive this type of error in the build
as with the merged wrappers the CLRTestTargetUnsupported clauses
need to be removed and replaced with ConditionalFactAttribute
annotations, otherwise we could lose part of the conditional
code coverage as in the lab the managed tests are build only
once on an arbitrary platform so their individual platform-specific
exclusions must be postponed to execution time.

Thanks

Tomas

[API Implementation]: Use TimeSpan everywhere we use an int for seconds, milliseconds, and timeouts (Group 1/3) (#64860)

* Do not reorder HTTP header values

* fix complie error

* make the changes @ danmoseley recommended

* make the changes @MihaZupan recommended

* make the changes @MihaZupan recommended

* make the changes @MihaZupan recommended

* make the changes @MihaZupan recommended

* make the changes @MihaZupan recommended

* check array length

* fix unit test

* Update src/libraries/System.Net.Http/tests/UnitTests/Headers/HttpHeadersTest.cs
Co-authored-by: NMiha Zupan <mihazupan.zupan1@gmail.com>

* Update src/libraries/System.Net.Http/src/System/Net/Http/Headers/HttpHeaders.cs
Co-authored-by: NMiha Zupan <mihazupan.zupan1@gmail.com>

* Update src/libraries/System.Net.Http/src/System/Net/Http/Headers/HttpHeaders.cs
Co-authored-by: NMiha Zupan <mihazupan.zupan1@gmail.com>

* Update src/libraries/System.Net.Http/src/System/Net/Http/Headers/HttpHeaders.cs
Co-authored-by: NMiha Zupan <mihazupan.zupan1@gmail.com>

* make the changes @MihaZupan recommended

* Update src/libraries/System.Net.Http/src/System/Net/Http/Headers/CacheControlHeaderParser.cs
Co-authored-by: NMiha Zupan <mihazupan.zupan1@gmail.com>

* chang unit test

* GetParsedValueLength

* fix build error

* Update src/libraries/System.Net.Http/src/System/Net/Http/Headers/CacheControlHeaderParser.cs
Co-authored-by: NMiha Zupan <mihazupan.zupan1@gmail.com>

* Update src/libraries/System.Net.Http/src/System/Net/Http/Headers/HttpHeaders.cs
Co-authored-by: NMiha Zupan <mihazupan.zupan1@gmail.com>

* unit test

* make changes @geoffkizer recommended

* CloneAndAddValue for InvalidValues

* Update src/libraries/System.Net.Http/src/System/Net/Http/Headers/HttpHeaders.cs
Co-authored-by: NMiha Zupan <mihazupan.zupan1@gmail.com>

* Update src/libraries/System.Net.Http/src/System/Net/Http/Headers/HttpHeaders.cs
Co-authored-by: NMiha Zupan <mihazupan.zupan1@gmail.com>

* Final nits
Co-authored-by: NMiha Zupan <mihazupan.zupan1@gmail.com>

* CI matrix change: Windows

* Remove Windows Server RS5

* Revert .net Framework change

* Add 19H1 to rolling

* Add Windows.Server.Core.20H2 to CI matrix

* Remove Windows 8.1

* Remove 20H2 as thhere is a PR for it #60054

* Typo
Co-authored-by: NJan Jahoda <jajahoda@microsoft.com>
Co-authored-by: NAndy Gocke <andy@commentout.net>
Co-authored-by: NDan Moseley <danmose@microsoft.com>

* Don't attempt to apply IMAGE_REL_BASED_REL32 when address doesn't belong to current block in src/coreclr/ToolBox/superpmi/superpmi-shared/compileresult.cpp

* Update "Exit Codes" section in the superpmi help command output

I originally hit this bug when testing my Crossgen2 perf optimization
change involving only registering composite code range once but I
managed to disprove the bug was caused by this change. Indeed, it
was caused by my earlier change improving component assembly caching.

In my overzealous attempt to make sure the assembly gets always
registered I added a new method NativeImage::AddComponentAssemblyToCache
that registered the assembly which had triggered the native image load
in the first place. This was incorrect, by that point the assembly
wasn't yet fully initialized and putting it in the cache made it
visible to other threads that subsequently crashed trying to access
the assembly before it was fully loaded.

Furthermore it was unnecessary, once the assembly gets loaded, it
gets stored in the cache via the call to
SetNativeMetadataAssemblyRefInCache from ZapSig::DecodeModuleFromIndex.
Before the fix I was able to repro the bug locally typically after
about 500 iterations of the thread14 unit test, with the fix I was
unable to repro after 4500 iterations.

Thanks

Tomas

Fixes: https://github.com/dotnet/runtime/issues/66954
Probably also fixes: https://github.com/dotnet/runtime/issues/66210