@manodasanW it seems this test is very flaky, I'm getting random failures always from that one across PRs 🤔

Failed UnitTest.TestCSharp.TestProxiedDelegate [1 s]
Error Message:
 System.Runtime.InteropServices.COMException : 
Stack Trace:
   at WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|39_0(Int32 hr)
 at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32 hr)
 at ABI.Windows.Foundation.AsyncActionCompletedHandler.NativeDelegateWrapper.Invoke(IAsyncAction asyncInfo, AsyncStatus asyncStatus)
 at UnitTest.OOPAsyncAction.Close() in D:\a\1\s\src\Tests\UnitTest\OOPObject.cs:line 107
 at UnitTest.TestCSharp.TestProxiedDelegate() in D:\a\1\s\src\Tests\UnitTest\TestComponentCSharp_Tests.cs:line 2927
 at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
 at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

@manodasanW it seems this test is very flaky, I'm getting random failures always from that one across PRs 🤔

Failed UnitTest.TestCSharp.TestProxiedDelegate [1 s]
Error Message:
 System.Runtime.InteropServices.COMException : 
Stack Trace:
   at WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|39_0(Int32 hr)
 at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32 hr)
 at ABI.Windows.Foundation.AsyncActionCompletedHandler.NativeDelegateWrapper.Invoke(IAsyncAction asyncInfo, AsyncStatus asyncStatus)
 at UnitTest.OOPAsyncAction.Close() in D:\a\1\s\src\Tests\UnitTest\OOPObject.cs:line 107
 at UnitTest.TestCSharp.TestProxiedDelegate() in D:\a\1\s\src\Tests\UnitTest\TestComponentCSharp_Tests.cs:line 2927
 at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
 at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

Yes, that test is indeed a known flaky one. It got flakier recently for some reason (probably a timing issue). A rerun typically makes it pass. That test does needs to be looked into to make it more reliable but so far it has been hard to repro locally.

How is repeating the same expression typeof(T) multiple times helping the linker? Is typeof(T) cheap enough to just repeat it a bunch of times?

"How is repeating the same expression typeof(T) multiple times helping the linker?"

typeof(T) is a JIT time constant and the IL scanner can also infer information from it. If we cache it in a local instead, the flow analysis loses track of it and then it can no longer eliminate branches, because it can't know they won't ever be taken.

"Is typeof(T) cheap enough to just repeat it a bunch of times?"

It's essentially free, yes. On .NET 8+:

• For direct type comparisons for value type generics, it's a constant
• For direct type comparisons for reference type generics, it's a direct method table comparison
• Anywhere else, it's just loading the baked address of the Type instance from the frozen object heap

So essentially it's super fast and you should never cache it, that's effectively a de-optimization. It can technically be beneficial to cache it on .NET Framework since that doesn't apply there, but I don't think we really care about that anyway.