Wow, I had no idea that MdArray-1=>SzArray horsetrade was so deeply embedded into the runtime.

Since you've put that logic into RuntimeAugments.NewMultiDimArray(), you can get rid of these checks:

https://github.com/dotnet/corert/blob/master/src/System.Private.Reflection.Core/src/System/Reflection/Runtime/TypeInfos/RuntimeArrayTypeInfo.cs#L68

https://github.com/dotnet/corert/blob/master/src/System.Private.CoreLib/src/System/Array.CoreRT.cs#L184

Since you've put that logic into RuntimeAugments.NewMultiDimArray(), you can get rid of these checks

Checks removed.

@davidwrighton PTAL

Now that I've slept on it, I thinking that the way to deal with newobj instance void int32[0...]::.ctor(int32) should be either one of these:

1. Have codegen lower this into the appropriate constructor call. We would revert my change to Internal/Runtime/CompilerHelpers/ArrayHelpers.cs and replace it with an assert that if rank is 1, lower bounds are non-zero. Codegen is already aware of this weirdness because it needs to special case rank 1 arrays with 0 lower bounds in RuntimeHelpers.InitializeArray expansion to prevent a heap corruption that would result from assuming a normal mdarray got allocated by the ctor call.
2. Add an optional field to rank 1 array EEType that points to the appropriate SzArray so that we can get to it relatively quickly.

My preference is 1.

Is it going to need a follow up change in ProjectN

If we want newobj instance void int32[0...]::.ctor(int32) to work, it will be some NUTC work. Project N will still benefit from the type loader being able to dynamically load these now (which is what the original bug in CoreFX was about). The newobj path is not reachable from C#, but the dynamic load one is.

I can file a bug if you think we should support this, but we'll get a reminder about this when NUTC starts running against the CoreCLR test assets. I checked in a test for this a month ago or so.

System.Private.Reflection.Execution/src/Internal/Reflection/Execution/TypeLoader/TypeCast.cs is missing the changes needed for this change. (In fact it appears to be missing array rank checks entirely).

System.Private.Reflection.Execution/src/Internal/Reflection/Execution/TypeLoader/TypeCast.cs is missing the changes needed for this change

The method in TypeCast.cs where I had to do the change in Runtime.Base is not mirrored in that TypeCast.cs, so no changes are needed. The various IsArray/GetArrayRank checks are suspect, but it's a separate issue (it will lead to e.g. incorrectly considering Foo[] and Foo[*] identical type). Proper fix for that only became possible very recently (reflection didn't use to have a way to tell between rank 1 MdArray and SzArray). I'll open a separate issue/pull request.

I have also validated that the (yet another) copy of casting logic in System.Reflection.Runtime.General.Assignability already handles this case correctly.