Merge nmirror to master

…y computed results (90% perf improvement on Release builds for the ASPNet benchmark app (22 mins to 2 mins total compile time) (#3652)

* update ObjectWriter

* small types fixes

* CodeView: ArrayType

* Use mangled names

CV has unique indexes and use them to link types inside, but somehow
not-unique names create conflicts. Use mangled names to avoid them.

* Use an Object Initializer

Merge nmirror to master

* Make calling Rank 1 MdArray ctor more reliable. This is not a great
fix (great fix would be one of the two options I enumerated in #3610),
but at least makes the problem go away. It's unlikely anyone is going to
use this anyway.
* Fix exception types we throw.

We'll want to allow compiler driver users to pick and configure the
metadata manager to their liking.

With some changes I have in flight `GetFinalizer` in compiler traces
went from "might be worth looking into making this faster" to "we spend
15% of compilation time here".

The answer to `HasFinalizer` is cheap to cache and reduces the pressure
on `GetFinalizer` significantly.

This is in preparation to moving reflection metadata analysis to the
scanning phase.

* Metadata needs are modeled in the dependency analysis engine:
`TypeMetadataNode`/`MethodMetadataNode`/`ModuleMetadataNode` now model
the metadata needs of individual types. We no longer use list of
generated EETypes/Methods to drive metadata generation.
* Dependencies of custom attributes are now correctly modeled. We no
longer end up with custom attributes that are useless at runtime and
crash with TypeLoadExceptions (cough, in ResourceManager, cough)
* Reflection blocking now applies when emitting invoke mapping tables
* MetadataBlocking policy is now a reusable object (we'll need to reuse
it between the metadata manager used for scanning for reflection use and
metadata manager used at compile time when we no longer analyze
reflection).
* We now correctly filter special methods that are not eligible to be in
the mapping tables (cctors, finalizers, etc.).

Generic interface types have a generic dictionary slot like any other
type, except sometimes the slot is null.

We can now call static methods on generic interfaces with a usable
generic context.

Got reminded of this while reading about the planned C# language support
for static methods on interfaces. I didn't want to push on it when #3100
added the logic, but it turns out this is really easy.

* Add PreInitFieldInfo that extracts preinitialized data information from fields that have [PreInitialized] and [InitDataBlob] pointing to RVA field
* Added FrozenArrayNode for frozen arrays with data extracted from preinit RVA data field
* Added GCStaticsPreInitDataNode (CoreRT only) to hold GC pointers for GC static fields. Pre-init data fields points to frozen data, while other data initialized to null. 
* Changed GCStaticsNode to emit a pointer reloc to GCStaticspreInitDataNode and mask 0x2 for the GC static EEType. 
* Changed InitializedStatics in StartupCodeHelper to check for 0x2 and memcpy the GC field data as needed
* Fixed a bug in bad GCStaticsEETypeNode size calculation - it's off-by-1 as static GC static field layout in CoreRT includes EEType already.

This was needed when we weren't using the type loader to load invoke
stub dictionaries. This hasn't been needed for months.

…ngHelper (#3666)

* Handling interface->object assignment + test
* Adapted logic in CanCastToClass and use CastingHelper.CanCastTo in IsAssignable(TypeDesc src, TypeDesc dst)

Merge nmirror to master

This lets RyuJIT optimize range checks on Span same way as it does for
arrays.

* Annotate the intrinsics
* Uncomment them in the table
* Report `sigInst` for all intrinsics

)

This api was approved here:

  https://github.com/dotnet/corefx/issues/5884

and is a necessary step to fixing the System.Dynamic.Runtime.Tests
failure:

  https://github.com/dotnet/corefx/issues/19895

which is caused by Microsoft.CSharp trying to do the impossible
and emulate this api without GetMetadataToken() support.

This approach opts for the most straightforward and efficient
implementation without any special-casing for weird situations
(this is also what Microsoft.CSharp implements today as
well as what someone else trying to trampoline members
across generic instantaitions is like to do.)

This results in the following behavior for these
corner cases. With the possible exception of #3,
I think they are tolerable enough to accept and codify:

1. "other" implemented by an entirely different Reflection
   provider than "this".

   Behavior:
     returns false without invoking any methods on the
     "other" Member.

   To change it to throw an ArgumentException would
   mean extra cast checks against the 6 possible
   Runtime types (or having said RuntimeTypes implement
   a sentinel interface.)

   Given that HasSameMetadataDefinitionAs() is a
   "looser cousin of Equals()" and "Equals()"
   doesn't throw for objects from a different universe,
   this seems reasonable.

2. Arrays, ByRefs, Pointers and Types from GetTypeFromCLSID()

   Behavior:
     Arrays, ByRefs, Pointers all return token 0x0600000
     and so they'll return "true" wrt to each other (provided
     both types are implemented by the same provider.)

     CLSID types all return the typedef of __ComObject
     so they'll return "true" wrt to each other.

     The constructor exposed by CLSID types all return
     the typedef of some constructor on __ComObject so
     they'll return "true" wrt to each other.

   I do not think these are interesting cases that merit
   special handling. These types will never appear
   in an enumeration of the members of a type. (The
   fact that Reflection surfaces them in objects
   that are assignable to MemberInfo is a structural
   flaw in Reflection's object model.)

3. Synthesized constructors and methods on array types.

   Behavior:
     These methods all return 0x06000000 as a token
     so the constructors will all compare true wrt
     each other, and likewise with the methods.

   This is a bit crummy though it's not clear
   what the "right" policy should look like.
   I could be persuaded to throw NotSupported
   for these, to leave the possibility open
   for a better story later. On the other hand,
   I wouldn't demand it either.

Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>

Signed-off-by: UIDL YGEN <uidlygen@yandex.ru>

)

* Update Unix SafeHandle to throw NotFound correctly

Need to match Windows semantics for missing files. This means throwing
FileNotFound only if the last segment of the path can't be found.

* Dispose handle and trim ending separator properly

Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>

Make metadata generation dependency driven

* Add PreInitData test and simple plumbing for ilproj
* make preinitdata.sh executable
* Add license header

Building against the lightweight version of S.P.CoreLib has bitrotted
over the past year. The classlib is handy for codegen and architecture
bringups and we might want to use it when getting rid of ready to run
helpers.

* Optimize ObjectWriter to emit series of bytes

Writing each byte of an `ObjectNode` out to the object file one by one
is inefficient. We also cannot emit all the bytes of an `ObjectNode` at
once because of the streaming nature of the LLVM API. Relocs, CFI info,
and symbol definitions are all interruptions emitted at specific points
in the stream. Optimize the current implementation by calculating the
longest run of bytes between each required interruption.

Testing on a large app, ASP.NET Core, this yields a 4% reduction in
total compilation time. The total time to compile (collected in Release
mode averaged over 5 runs) decreased from 31611ms to 30345ms. A further
gain may be possible when we get a high performance implementation of
Span<T>, able to efficiently pin the byte arrays we pass to native.

Removes SerializableAttribute from CoreCLR types not intended to be serializable as well as adding special handling to MulticastDelegate to prevent serializing delegates (which can't be correctly serialized cross platform/runtime).

Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>

Case insensitive get operation throw
KeyNotFoundException since the underlying
implemention use Dictonery instead of
HashTable.
var set = GetSet(StaticResources.WithData);
// this succeed
set.GetString("String"));
// this is supposed to work,but throws
// KeyNotFound
set.GetString("string", true));

Picks up dotnet/coreclr#11780.

add S_UDT symbols to the object file.
It fixes #3538