Add support for statics access from shared generic code, as well as precise-init static class construction

[davidwrighton]

• There is another renaming of the helpers call opcodes to allow distinguishing between whether or not the arg is supplied via svar or dataindex.
• More tests to cover these scenarios
• This should finish up the support for shared generics

[Copilot]

Pull Request Overview

This PR extends the interpreter to distinguish helper call opcodes based on how arguments are supplied (via static var vs. data index) and adds support for precise static constructor initialization in shared generic code.

• Introduces new opcodes (INTOP_CALL_HELPER_P_S, _PS, _SP, _GS, _APS, _AGS) in both the opcode definitions and interpreter execution.
• Updates the compiler to emit the new opcodes and to insert precise-init calls for initClass at method start and on static field access.
• Adds TestPreciseInitCctors in the interpreter tests to verify that static constructors run exactly when expected.

Reviewed Changes

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

Show a summary per file

File	Description
src/tests/JIT/interpreter/Interpreter.cs	Added TestPreciseInitCctors; hooked it into RunInterpreterTests
src/coreclr/vm/interpexec.cpp	Expanded switch to handle new helper‐call opcodes
src/coreclr/interpreter/intops.h	Declared InterpOpHelperFtnNoArgs for no-argument helpers
src/coreclr/interpreter/intops.def	Defined new opcodes (_S, _PS, _SP, _GS, _APS, _AGS)
src/coreclr/interpreter/compiler.cpp	Emit new opcodes in EmitPushHelperCall_*, insert precise-init logic, update PrintInsData

Comments suppressed due to low confidence (5)

src/coreclr/interpreter/compiler.cpp:3318

• New code paths for method‐start initClass and the subsequent runtime‐lookup branches (CORINFO_LOOKUP_THISOBJ, METHODPARAM, etc.) aren't covered by existing interpreter tests. Add tests in Interpreter.cs to exercise these branches and validate that the correct helper opcodes are emitted and executed.

    CorInfoInitClassResult initOnFunctionStart = m_compHnd->initClass(NULL, NULL, METHOD_BEING_COMPILED_CONTEXT());

src/tests/JIT/interpreter/Interpreter.cs:1996

• The error message references TriggerCctorClass even though this branch tests TriggerCctorMethod. Also it doesn't show the actual preciseInitCctorsRun value. Consider using Console.WriteLine("preciseInitCctorsRun should be 2, but is {0}", preciseInitCctorsRun); for clarity.

            Console.WriteLine("TriggerCctorClass should return 2, but did not");

src/tests/JIT/interpreter/Interpreter.cs:2003

• Same issue as above: this branch follows new MyPreciseInitClass<double>() but prints the wrong helper name and omits the actual counter value. Update to reference preciseInitCctorsRun with the expected versus actual value.

            Console.WriteLine("TriggerCctorClass should return 3, but did not");

src/tests/JIT/interpreter/Interpreter.cs:2016

• This message is in the branch testing TriggerCctorMethod<object>() but again calls out the wrong helper name and hides the counter. Use a consistent message like preciseInitCctorsRun should be 5, but is {0}.

            Console.WriteLine("TriggerCctorClass should return 5, but did not");

src/tests/JIT/interpreter/Interpreter.cs:2023

• Similarly, this branch tests the constructor on MyPreciseInitClass<Type>() but the message refers to TriggerCctorClass and omits the run count. Consider using the actual preciseInitCctorsRun in the output for easy debugging.

            Console.WriteLine("TriggerCctorClass should return 6, but did not");

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad, @janvorli, @kg
See info in area-owners.md if you want to be subscribed.