Work around issue #102868 (#102982)

The relaxation of type layout check in #102810 exposed a bug in the type layout algorithm that doesn't correctly handle doing type layout in this situation (it doesn't match what CoreCLR VM computes). This restores the old behavior for ReadyToRun that just throws on this. The compiler will then stop precompiling the method and fall back to runtime JIT. Works around #102868 (the bug still exists, this is a valid situation that we should be able to precompile, we just won't).
dotnet · Jun 4, 2024 · 1c683a8 · 1c683a8
1 parent 015e46e
commit 1c683a8
Showing 1 changed file with 14 additions and 0 deletions.
diff --git a/...oreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunMetadataFieldLayoutAlgorithm.cs b/...oreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunMetadataFieldLayoutAlgorithm.cs
@@ -818,10 +818,24 @@ protected override ComputedInstanceFieldLayout ComputeInstanceFieldLayout(Metada
         {
             if (type.IsExplicitLayout)
             {
+                // Works around https://github.com/dotnet/runtime/issues/102868
+                if (!type.IsValueType &&
+                    (type.MetadataBaseType is MetadataType baseType && baseType.IsSequentialLayout))
+                {
+                    ThrowHelper.ThrowTypeLoadException(type);
+                }
+
                 return ComputeExplicitFieldLayout(type, numInstanceFields);
             }
             else if (type.IsSequentialLayout && !type.ContainsGCPointers)
             {
+                // Works around https://github.com/dotnet/runtime/issues/102868
+                if (!type.IsValueType &&
+                    (type.MetadataBaseType is MetadataType baseType && baseType.IsExplicitLayout))
+                {
+                    ThrowHelper.ThrowTypeLoadException(type);
+                }
+
                 return ComputeSequentialFieldLayout(type, numInstanceFields);
             }
             else