Release/3.1 port of dotnet/runtime#239 (#27973)

Fix for #27923

The jit might fail to locate a class handle for a ref class, leading to an
unexpected crash while jitting.

## Customer Impact
Unexpected and hard to diagnose crash/exception

## Regression?
Yes, introduced during the development 3.0 cycle. 2.x behaves correctly.

## Testing
Verified the user's test case now passes; no diffs seen in any existing
framework or test code.

## Risk
**Low**: the jit will now fall back to using the handle for System.Object if no
better option can be found.

cc @BruceForstall

____

In some cases we may end up in lvaSetClass without a valid ref class handle
from either the IR or the stack. Use the handle for object as a conservative
fallback.

1 files changed, 5 insertions, 1 deletions

diff --git a/src/jit/lclvars.cpp b/src/jit/lclvars.cpp
index 70cc7fe175..dbfab7afea 100644
--- a/src/jit/lclvars.cpp
+++ b/src/jit/lclvars.cpp
@@ -2699,7 +2699,7 @@ void Compiler::lvaSetClass(unsigned varNum, CORINFO_CLASS_HANDLE clsHnd, bool is
 // Notes:
 //    Preferentially uses the tree's type, when available. Since not all
 //    tree kinds can track ref types, the stack type is used as a
-//    fallback.
+//    fallback. If there is no stack type, then the class is set to object.
 
 void Compiler::lvaSetClass(unsigned varNum, GenTree* tree, CORINFO_CLASS_HANDLE stackHnd)
 {
@@ -2715,6 +2715,10 @@ void Compiler::lvaSetClass(unsigned varNum, GenTree* tree, CORINFO_CLASS_HANDLE
     {
         lvaSetClass(varNum, stackHnd);
     }
+    else
+    {
+        lvaSetClass(varNum, impGetObjectClass());
+    }
 }
 
 //------------------------------------------------------------------------