Make Expr(:invoke) target be a CodeInstance, not MethodInstance #54899
+65
−32
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 is a look at what is necessary and what it would look like for codegen to be using CodeInstance directly to get the API for a function call (specifically the rettype), rather than using a lookup call at that point to decide upon the API. It is based around the idea that eventually we would keep track of these anyways to form a graph of the inferred edge data, for use later in validation anyways (instead of attempting to invert the backedges graph in staticdata_utils.c), so we might as well use the same target type for the :invoke call representation also.
This does not depend upon #54894, but is much better with it. It did depend upon #54738, though there still remains work to do to teach it how to select a correct alternative CodeInstance after deserializing. Also still to do: codegen also should be looking for equivalent objects, not just using the exact one given, per the definition of equivalency in https://hackmd.io/@vtjnash/codeinstances (and that is what precompile should be doing also).