Legend:

- ~~The Parrot_call_sub_* and Parrot_call_method_* variants in src/extend.c don't all have the necessary changes to allow them to work with the new calling conventions (these are temporary implementations for backward compatibility before they're removed at the next deprecation point). Parrot_call_sub does have the right changes, and the others can be largely copied from it.~~

99

100

- ~~NCI hasn't been fully updated on caller and receiver side to use the new argument passing style.~~

- Parrot_pcc_fill_params_from_op and Parrot_pcc_fill_params_from_c_args are monolithic functions (basically finite state machines iterating over the arguments), that contain a great deal of nearly repeated code (one or two things different each time). Parrot_pcc_fill_returns_from_op and Parrot_pcc_fill_returns_from_c_args will be just as bad once they support all the options. Not a requirement before the merge, but these should be refactored into smaller subroutines. Needs to be thought through carefully though, it was a similar plan that lead to the current mess.

105

106

- Flattening an argument doesn't alter the signature string stored, so multiple dispatch can't handle the resulting string. Need to modify the signature string while building the CallSignature object. (t/pmc/multisub.t and t/pmc/multidispatch.t)

- Likely cases of code still calling into the old functions for invoking from C, instead of the new functions (t/pmc/sub.t, t/pmc/threads.t)

127

128

- Likely bug in Parrot_call_sub reimplementation (t/src/embed.t)

129

130

- miniparrot fails to compile if an installed parrot is not already present, because it has -lparrot in the compile options

131

132

- Make sure the API and documentation consistently uses "args" and "returns" to mean "the things passed into the call or return" and "params" and "results" to mean "the things extracted from the call or return".

133

134

- ~~Currently, test_more.pir cannot be used on pcc_reapply. Attempting to use test_more.pir results in~~