Prior to this commit, KeywordParameterNode included both optional
and required keywords. With this commit, it is split in two, with
`OptionalKeywordParameterNode`s no longer having a value field.
89084d9af4
* This was causing this error on macOS Mojave:
src/prism.c:8216:48: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
pm_token_buffer_t token_buffer = { 0 };
^
5055fc04fd
Method calls with keyword splat args compile differently than
without since they merge the keyword arg hash with the keyword splat
hash. We know this information at parse time, so can set a flag
which the compiler can use.
e5f8a9a3cd
pm_scope_node_init is only used for CRuby, so should not live in the
ruby/prism repo. We will merge the changes here first so they're
not breaking, and will then remove from ruby/prism
Right now, our Call{Operator,And,Or}WriteNode nodes represent two
different concepts:
```ruby
foo.bar += 1
foo[bar] += 1
```
These two statements are different in what they can support. The
former can never have arguments (or an opening_loc or closing_loc).
The former can also never have a block. Also, the former is a
variable method name.
The latter is always going to be []/[]=, it can have any number of
arguments including blocks (`foo[&bar] ||= 1`), and will always
have an opening_loc and closing_loc.
Furthermore, these statements end of having to take different paths
through the various compilers because with the latter you have to
consider the arguments and the block, whereas the former can
perform some additional peephole optimizations since there are
fewer values on the stack.
For these reasons, I'm introducing Index{Operator,And,Or}WriteNode.
These nodes never have a read_name or write_name on them because
they are always []/[]=. They also support blocks, which the previous
write nodes didn't. As a benefit of introducing these nodes, I've
removed the opening_loc, closing_loc, and arguments from the older
write nodes because they will always be null.
For the serialized format, both of these nodes end up being
smaller, and for in-memory we're storing fewer things in general,
so we have savings all around.
I don't love that we are introducing another node that is a call
node since we generally want consumers to only have to handle a
single call, but these nodes are so specific that they would have
to be handled separately anyway since in fact call 2 methods.
70155db9cd
