Before this commit, we were mixing a lot of concerns with the prism
compile between RubyVM::InstructionSequence and the general entry
points to the prism parser/compiler.
This commit makes all of the various prism-related APIs mirror
their corresponding APIs in the existing parser/compiler. This means
we now have the correct frame naming, and it's much easier to follow
where the logic actually flows. Furthermore this consolidates a lot
of the prism initialization, making it easier to see where we could
potentially be raising errors.
If the first element of an interpolated string node is an embedded
statement, CRuby "pre-initializes" the interpolation with a string of
known encoding to concat into.
This patch replicates thate behaviour in Prism
On s390x, a long is 8 bytes. st_data_t is an unsigned long but
pm_constant_id_t is a 4 byte integer. We need to cast it to st_data_t
when passing it to ST functions.
We need to make sure there is enough room in the local table for
repeated `*_` parameters
Co-Authored-By: Matt Valentine-House <matt@eightbitraptor.com>
Prism provides an index (local_body_index) which is supposed to point at
the start of locals declared in the method body. Prism assumed that
method body locals would only occur _after_ parameter names.
Unfortunately this assumption is not correct, which meant that we would
in some cases not insert all locals in the local table. This commit
iterates over locals a second time, inserting any that didn't get
inserted on the first pass.
Fixes: https://github.com/ruby/prism/issues/2245
Co-Authored-By: Matt Valentine-House <matt@eightbitraptor.com>
Previously, we were using the main pm_compile_node switch to compile
target nodes. Eventually we switched to pm_compile_target_node and
updated all the call sites. As such, all of this has become dead
code.
However, the multi target code was reused for both parameters and
multi writes (it was just incorrect for multi writes). So that code
has now been moved into its own function that is more specific to
destructured parameters (and has more assertions to that effect).
Overall now you should not see target nodes when you call into
pm_compile_node, since they are more specialized and require more
special handling.
