We were using a null logger.

Contributes to #32648

* add flags checks to BMI1 intrinsic lowering to prevent decomposed longs in x84 from being altered

* update bmji1intrinsics tests

Updates include:
- Use LLVM 13.0.1
- Use Visual Studio 2022 for building on Windows
- Use Ubuntu 18.04 containers for building on Linux

Binaries built from: https://github.com/dotnet/jitutils/pull/351

Unspilling could produce too narrow loads for normalize-on-load
variables when encountering a narrowly typed LCL_VAR node. This could
result in subsequent uses of the same local using a truncated value.

Fix #66624

According to our design discussions we have decided to keep
the 'issues.targets' file for disabling tests before the
test refactoring has been completed as otherwise we would
have a subset of issue exclusions in 'issues.targets' and
the rest in 'ActiveIssue' test annotations making it very
hard to understand for developers and test monitors.

Moreover today implementation of ActiveIssue is not rich enough
to express all conditional test disabling clauses in issues.targets
so the bug migration will require a bit of additional design work
and we don't want to block the migration on that. This simple change
uses the existing infrastructure to emit a "test exclusion list"
under CORE_ROOT for the particular targeting OS, architecture and
build mode that gets subsequently consumed by the merged test
wrapper in Helix and used to skip the blocked tests.

Thanks

Tomas

Because OSR funclet frames must pad with Tier0 frame size, initial SP delta
may exceed 240 bytes.

Fixes #65996.

Fixes #66781

* Avoid IntPtr[] allocation in Associates.AssignAssociates

* Address PR feedback (and as a result use stack space in a few more related places)

The --llvmonly mode is not used in production, it also doesn't
have correct EH semantics.

* Disabled System.Security.Cryptography.Tests.

* Applied @mdh1418 suggestion.

* Removed empty line.

* do not copy redist files to artefacts

* do not copy redist files to tests

* Do not include Redist files in runtime packs

These triggered a warning in the new clang included with Xcode 13.3

* Dedup patterm/options/timeout in Regex source generator

If we end up with multiple identical pattern/options/timeout tuples in the same assembly, we don't need to emit unique code for each.  We can still emit the partial implementation for each, but emit a single implementation of the Regex they all share.

* Make the cached Regex members be static readonly fields

No reason we need a property here wrapping a compiler-generated backing field.

Rather than ToString'ing everything, most of the header data can be formatted into a span and then written out to the writer.

They are not used by the rest of the runtime and we only need a bare minimum of w32process and w32file in eventpipe (e.g. no file share/access logic).

Fix ep-test build and warnings, it was missing linking against libz and monoapi.

Fix host vs. target confusion in ep-rt-mono.c

Move initialization of num_main_args after setting main_args in object.c so we can use it as a cheap guard value (not totally thread-safe but good enough for our purposes).
Co-authored-by: NJohan Lorensson <lateralusx.github@gmail.com>

* First pass

* Second pass

* Pass three

* Missed few things

* ref

* Update ProviderAliasUtilities.cs

* Update ActivityTrackingOptions.cs

* Update Microsoft.Extensions.Logging.cs

* GetRequiredService

* Update Logger.Scope

* Create CompatibilitySuppressions.xml

* Add comment to CompatibilitySuppressions.xml
Co-authored-by: NJose Perez Rodriguez <joperezr@microsoft.com>

* Delete CompatibilitySuppressions.xml

* AsyncLocal<Scope?> _currentScope

* Add assert
Co-authored-by: NJose Perez Rodriguez <joperezr@microsoft.com>

Fully implement support for the `NewTypeDefinition` EnC capability: a hot reload edit can add a new type definition (class, struct, interface, enum) that contains new fields, methods, properties, events, and nested classes, and can have generic params.  Also add reflection support for all of the above.

This is sufficient to support hot reload of types tagged with [`CreateNewOnMetadataUpdateAttribute`](https://docs.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.createnewonmetadataupdateattribute?view=net-6.0).

Contributes to https://github.com/dotnet/runtime/issues/63643 and https://github.com/dotnet/runtime/issues/57365

---

The implementation introduces `MonoAddedDefSkeleton` which is a bookkeeping structure that records the metadata indexes of where to find methods, fields, properties and events for a newly-added class.  The issue is that normally `mono_class_create_from_typedef` expects to find all that stuff in a contiguous block starting at the row pointed by the `MONO_TYPEDEF_FIELD_LIST` or `MONO_TYPEDEF_METHOD_LIST` columns of the new typedef.  But in EnC deltas, those columns are zeroed out, and instead the EnCLog functions like `ENC_FUNC_ADD_METHOD` and `ENC_FUNC_ADD_FIELD` explicitly record when a new row is added that is relevant to a particular type definition.

So during the pass over the EnCLog, we start creating skeletons when we see a new row added to the typedef table.  Then when we see the add functions, we record the row indices of the field, method, etc tables.  As far as I can tell, the rows for a particular type definition are contiguous, so we just record the first index and the count.

At the end of the pass, we save the skeletons on the metadata delta, and when code finally creates the `MonoClass` for a particular freshly-added type definition, we check the skeleton and use the recorded rows to populate the fields and methods.  Event and property data is created on-demand (the demand being reflection) in basically the same way.

One important note: we try very hard not to accidentally materialize a newly-added class as a `MonoClass` during the update itself - we need to at least get through the entire EnCLog - otherwise we might not see every field/method/etc and set up the class incorrectly.

The upshot is that the newly-added `MonoClass` behaves like any other "normal" class - all its fields are laid out normally (they're stored in the object, not in a separate hash table).  It can be generic.  It can have base types, interfaces, etc.

This is different from how added fields, props and events will be implemented on existing classes - we won't modify `MonoClass:fields` or the `MonoClassPropertyInfo:properties` arrays - once they have been allocated, we don't want to mess with them.  Instead additions to existing classes with create `MonoClassMetadataUpdateField` (`MonoClassMetadataUpdateProperty` and `MonoClassMetadataUpdateEvent`) structs that are going to be stored on the `MonoClassMetadataUpdateInfo` that's associated with each `MonoClass`.  The various iterators like `mono_class_get_fields` and `mono_class_get_props` will be modified to return the added fields/props/etc after the existing ones.

This is already implemented for fields.  Props and Events will be part of a separate effort to implement reflection support for them.

---

* Checkpoint. Infrastructure for added types

* register member->parent lookups for newly-added classes and members

* fix off by one error creating class from skeleton

* AddNestedClass test works with mono now; also make it generic

* checkpoint: adding properties

   it "works" but only because we don't look very hard for the new properties anywhere.  reflection is probably pretty broken.

* Add a property to AddNestedClass test

* remove allow class/field/method/property ifdefs

   keep the instance field ifdef for now

* add event to AddNestedClass

* add DISALLOW_BROKEN_PARENT ifdef

   allow CustomAttribute row modifications to change Parent, while https://github.com/dotnet/roslyn/issues/60125 is being sorted out

* checkpoint: adding events

* Add new test ReflectionAddNewType

* Add new types to the image name cache

* Assembly.GetTypes and additional tests

* Make nested types work

* GetInterfaces on new types; also Activator.CreateInstance

* Mark mono_class_get_nested_classes_property as a component API

   also mono_class_set_nested_classes_property

* Add GetMethods, GetFields, GetMethod, GetField test

* [class] Implement added method iteration

   Change the iterator from storing MonoMethod** values to storing an iteration count. For added methods, when the iteration count is more than mono_class_get_method_count, run through the hot reload added_members list and
iterate over any relevant methods

* Implement added field iteration

* Add a GetField(BindingFlags.Static) test case

* Add Enum.GetNames and GetProperties tests - not working yet

* Mark mono_class_get_method_count as a component API

   also mono_class_get_field_count

* Enum values work

* Use GSList for added_fields (and props, events); add from_update bit

   Use GSList to simplify the concurrency story for accessing added_fields (and added_props and added_events, eventually): unlike a GPtrArray it won't resize, so we don't need to lock readers.

   Add a from_update bit to MonoProperty and MonoEvent - when props or events are added to existing classes, they will have the bit set.  That means that pointer arithmetic to figure out the prop (or event) tokens won't be usable (since
they're not allocated in one big block).

* Reflection on props in new classes works

* events on new classes work

* Add CustomAttribute reflection test

* remove test for props on existing type - it's not part of this PR

* instance field additions to existing types aren't supported yet

* rm TODO and FIXME

* store prop and event from_update bit in attrs

   The upper 16 bits aren't used for ECMA flags, so grab a bit for metadata-update

* remove instance fields from reflection test

   since Mono doesn't support them yet

* make the Browser EAT lanes happy

   Add some fields to the baseline versions of some test assemblies to keep some types that are used in the deltas from getting trimmed away

In this scope, `__uint64_t` is not available on musl based systems. Switched to `guint64`, which nearby code is using.

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

* Implement missing SymUnmanaged* interfaces

* Add try-finally around GCHandle

* Marshal interface argument to pinned pointer

* Minor fixes

* Address feedbacks from review

* Reimplement stubs to improve performance

This change implements `FixupPrecodeStub`, `PrecodeStub`
and `CallCountingStub` using a new mechanism with fixed code and separate RW
data. The `LoaderHeap` was updated to support a new kind of allocation
using interleaved code and data pages to support this new mechanism.
The JIT now generates code that uses indirection slot to jump to the
methods using `FixupPrecode`, improving performance of the ASPNet
plaintext benchmark by 3-4% depending on the target platform (measured
on x64 Windows / Linux and arm64 Linux).

I have also removed the Holders, as the stubs are naturally properly
aligned due to the way they are allocated.

There is now only a single variant of each stub, there are no long /
short ones anymore as they are not needed - the indirect jumps we use
now are not range limited.

Most of the stubs stuff is now target agnostic and the originally split
implementation is now in single place for all targets. Only a few
constants are defined as target specific in these.

The code for the stubs is no longer generated as bytes by C++ code, but
rather written in asm and compiled. These precompiled templates are then
used as a source to copy the code from. The x86 is a bit more complex
than that due to the fact that it doesn't support PC relative indirect
addressing, so we need to relocate all access to the data slots when
generating the code pages.

As a further improvement, we could generate just a single page of the
code and then just map it many times. This is left for future work.

ARM64 Unix differs from the other targets / platforms - there are
various page sizes being used. So the asm templates are generated for
4k..64k page sizes and the variant is then picked at runtime based on
the page size extracted from the OS.

This also removes a lot of writeable mappings created for modifications
of the stub code when W^X is enabled, in the plaintext benchmark they
were reduced by 75%. That results in a significant reducing of the .NET
application startup time with W^X enabled.

I think the `LoaderHeap` would benefit from some refactoring, but I'd
prefer leaving it for a follow up. It seems that for the sake of the
review, it is better to keep it as is.

The change also implements logging of number of mappings and their exact
locations. This helped me to drive the work and I am planning to use it
for further changes. It can be removed in the future once we reach a
final state.

There are still opportunities for improvement, but these stubs allowed
me to scrape off the most significant portion of the mappings.