This follows in the footsteps of #573, where we introduced a standard IInvocation implementation type and re-used it for all methods of interface proxies without target. This present PR does the same for abstract methods of class proxies without target: those would always get a custom-built invocation type with identical InvokeMethodOnTarget implementations; so they, too, are eligible for invocation type reuse.
The tests cover all combinations of (a) abstract vs. virtual, (b) public vs. protected, and (c) generic vs. non-generic method:
(a) is in fact the only distinction that really matters.
This follows in the footsteps of #573, where we introduced a standard
IInvocationimplementation type and re-used it for all methods of interface proxies without target. This present PR does the same for abstract methods of class proxies without target: those would always get a custom-built invocation type with identicalInvokeMethodOnTargetimplementations; so they, too, are eligible for invocation type reuse.The tests cover all combinations of (a)
abstractvs.virtual, (b)publicvs.protected, and (c) generic vs. non-generic method:EmitCallThrowOnNoTargetapparently depends on the presence of a callback method, andprotectedwould regularly lead to callback methods being emitted.