Use standard invocation type for abstract methods of class proxies w/o target #626
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 identicalInvokeMethodOnTarget
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:EmitCallThrowOnNoTarget
apparently depends on the presence of a callback method, andprotected
would regularly lead to callback methods being emitted.