Remove getTypeForBoxOnStack from jit interface

[AndyAyersMS]

Along with the StackAllocatedBox type. The JIT can now represent on-stack boxes directly via class layouts.

Closes #114204

[AndyAyersMS]

@jakobbotsch PTAL
cc @dotnet/jit-contrib

[Copilot]

Copilot reviewed 16 out of 17 changed files in this pull request and generated 1 comment.

Files not reviewed (1)

• src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems: Language not supported

Comments suppressed due to low confidence (1)

src/coreclr/inc/corinfo.h:2481

• Confirm that all implementations of the ICorStaticInfo interface are updated to remove getTypeForBoxOnStack, ensuring interface consistency following its deletion.

virtual CORINFO_CLASS_HANDLE getTypeForBoxOnStack(CORINFO_CLASS_HANDLE cls) = 0;

[Copilot]

Ensure that the updated callback array size (changed from 177 to 176) accurately reflects the removal of the getTypeForBoxOnStack callback and that all subsequent callback indices have been correctly adjusted.

[AndyAyersMS]

I am seeing failures in System.Net.Http.Functional.Tests.PlatformHandler_HttpClientHandlerTest.GetAsync_ManyDifferentResponseHeaders_ParsedCorrectly that were not there before the recent merge: console log

Wondering if #114759 might be related?

@MihaZupan FYI

Same test is failing in #114785

[MihaZupan]

System.Net.Http.Functional.Tests.PlatformHandler_HttpClientHandlerTest.GetAsync_ManyDifferentResponseHeaders_ParsedCorrectly(newline: "\r\n", fold: "\r\n    ", dribble: True) [FAIL]
      Assert.Equal() Failure: Strings differ
                 ↓ (pos 0)
      Expected: "fname.ext"
      Actual:   ""fname.ext""

That's #114771, specifically the tests against .NET Framework, cc: @ManickaP.
I do see the failure on that PR (Build windows-x86 Release Libraries_NET481 failed), but build analysis was green 😕

[AndyAyersMS]

System.Net.Http.Functional.Tests.PlatformHandler_HttpClientHandlerTest.GetAsync_ManyDifferentResponseHeaders_ParsedCorrectly(newline: "\r\n", fold: "\r\n    ", dribble: True) [FAIL]
      Assert.Equal() Failure: Strings differ
                 ↓ (pos 0)
      Expected: "fname.ext"
      Actual:   ""fname.ext""

That's #114771, specifically the tests against .NET Framework, cc: @ManickaP. I do see the failure on that PR (Build windows-x86 Release Libraries_NET481 failed), but build analysis was green 😕

Opened #114790

[hez2010]

Does this support representing a boxed nullable value type as well?

[AndyAyersMS]

Does this support representing a boxed nullable value type as well?

See #114716, though likely we never change types here as nullable box allocation happens via helpers currently, and once we do that we will need to call the getTypeForBox earlier.

[AndyAyersMS]

Pretty sure none of these failures are related. There seems to be one test failure not covered by build analysis, it's a timeout in remote executor: #108210 (comment)