The regression test

<code>src\tests\JIT\Regressions\JitBlue\Runtime_46239</code>

exercises various interesting corner cases of type layout that
weren't handled properly in Crossgen2 on x86 and ARM[32]. This
change fixes the remaining deficiencies and it also adds
provisions for better runtime logging upon type layout mismatches.

Thanks

Tomas

With this change, the only remaining pipelines using Crossgen1 are
"r2r.yml", "r2r-extra.yml" and "release-tests.yml". I haven't yet
identified the pipeline running the "release-tests.yml" script;
for the "r2r*.yml", these now remain the only pipelines exercising
Crossgen1. I don't think it makes sense to switch them over to
CG2 as we already have their CG2 counterparts; my expectation is
that, once CG1 is finally decommissioned, they will be just deleted.

Thanks

Tomas

…ntial

I have basically reverted the marshalling code shuffles as they
are no longer necessary based on the direction suggested by JanK.
I haven't made the counterpart runtime changes yet, I'm running
an initial smoke test to see all the places that blow up.

Thanks

Tomas

Based on Jan's suggestion I have changed the runtime behavior to
align explicit layout structs by default. The funny part here was
that the implementation is two-tiered, split into the case with
vs. without layout metadata, using two completely different code
paths.

I have extracted a small part of the EEClassLayoutInfo
calculation dealing with primitive field size and alignment into
code usable by both codepaths to reduce code duplication. I have
also bumped up the R2R compatibility version information as this
is (intentionally) a globally breaking change for R2R images
produced by older versions.

As part of simplifying the various conditions I have deleted a
section that claims we shouldn't be updating the number of instance
bytes for blittable / managed sequential types. I just hope this
is no longer needed so that I don't have to redo the marshalling
helper shuffles again.

Thanks

Tomas

Per JanK's feedback I simplified CoreCLR runtime calculation of
explicit layout size but I missed that Crossgen2 actually differs
from it in a very subtle manner. This change fixes it by only
accepting the explicit size if it's larger than or equal to the
unaligned calculated explicit layout size.

Thanks

Tomas

… feedback

I have simplified runtime and Crossgen2 behavior in the presence
of sequential layout by removing blittability from the picture
as the IsBlittable check is very complex and hard to maintain in
sync between the native runtime and the managed compiler. I have
introduced a somewhat weaker and much simpler check
MayContainGCPointers that returns FALSE for all IsBlittable types
(and for a few others).

Thanks

Tomas

…back

In my investigation of the x86 failures I hit an interesting corner
case of the class GCMemoryInfoData that is checked for having managed
layout matching its native counterpart. Interestingly enough, that
only worked because the class internally reported as non-blittable
and not managed sequential so it ended up using the auto layout;
when my change switched it over to use the sequential layout, it
turned out that the sequential layout algorithm differs from its
native counterpart. While the change is technically breaking this
corner scenario, I suspect that the primary purpose of sequential
layout is interop with native code and I find the fact that it's
actuall mismatched concerning beyond the scope of my pending change.

Thanks

Tomas

I originally thought the modification may assist debugging layout
issues as I did during the investigation. It however turns out
that basically the same class name check can be put in
EEClassLayoutInfo::CollectLayoutFieldMetadataThrowing so I am
removing this as superfluous temporary instrumentation.

Thanks

Tomas