It's possible to repeat parameters in method definitions like so:
```ruby
def foo(_a, _a)
end
```
The compiler needs to know to adjust the local table size to account for
these duplicate names. We'll use the repeated parameter flag to account
for the extra stack space required
b443cb1f60
Co-Authored-By: Kevin Newton <kddnewton@gmail.com>
Co-Authored-By: Jemma Issroff <jemmaissroff@gmail.com>
Because this is a user-facing change, we also need to deal with the
fact that CRuby 3.3.0 was just released.
In order to support workflows that want to parse exactly as CRuby
parses in a specific version, this PR introduces a new option to
the options struct that is "version". This allows you to specify
that you want "3.3.0" parsing.
I'm not sure if this is the correct solution. Another solution is
to just fork and keep around the old branch for security patches.
Or we could keep around a copy of the source files within this
repository as another directory and only update when necessary.
There are a lot of potential solutions here.
Because this change is so small and the check for it is so minimal,
I've decided to go with this enum. If this ends up entirely
cluttering the codebase with version checks, we'll come up with
another solution. But for now this works, so we're going to go in
this direction for a bit until we determine it's no longer working.
d8c7e6bd10
The previous implementation was incorrect since it was just checking for all keys in assoc nodes to be static literals but the actual check is that all keys in assoc nodes must be symbol nodes.
This commit fixes that implementation, and, also, aliases the flag to `PM_KEYWORD_HASH_NODE_FLAGS_SYMBOL_KEYS` so that ruby/ruby can start using the new flag name.
I intend to later change the real flag name to `PM_KEYWORD_HASH_NODE_FLAGS_SYMBOL_KEYS` and remove the alias.
f5099c79ce
The previous implementation of hash deopt was based on clearing the static literal flag on a hash node if the element that was being added was an array, hash or range node, or if the element was not a static literal in the first place.
However, this is not correct. First of all, the elements added to a hash node will primarily be assoc nodes, but never array, hash or range nodes. Secondly, the static literal flag is set on assoc nodes, only if the value in an assoc node is a static literal, so the key is never checked. As a result, the static literal flag on a hash node would never be cleared if the key wasn't a static literal.
This commit fixes this by clearing the static literal flag if:
1. the element is not an assoc node,
2. the element is an assoc node, but the key is not a static literal, or
3. the element is an assoc node, the key is a static literal, but assoc node (and thus the value in assoc node) is not a static literal.
7f67109b36
In this commit we're splitting up the call nodes that were in target
positions (that is, for loop indices, rescue error captures, and
multi assign targets).
Previously, we would simply leave the call nodes in place. This had
the benefit of keeping the AST relatively simple, but had the
downside of not being very explicit. If a static analysis tool wanted
to only look at call nodes, it could easily be confused because the
method would have 1 fewer argument than it would actually be called
with.
This also brings some consistency to the AST. All of the nodes in
a target position are now *TargetNode nodes. These should all be
treated the same, and the call nodes can now be treated the same.
Finally, there is benefit to memory. Because being in a target
position ensures we don't have some fields, we can strip down the
number of fields on these nodes.
So this commit introduces two new nodes: CallTargetNode and
IndexTargetNode. For CallTargetNode we get to drop the opening_loc,
closing_loc, arguments, and block. Those can never be present. We
also get to mark their fields as non-null, so they will always be
seen as present.
The IndexTargetNode keeps around most of its fields but gets to
drop both the name (because it will always be []=) and the
message_loc (which was always super confusing because it included
the arguments by virtue of being inside the []).
Overall, this adds complexity to the AST at the expense of memory
savings and explicitness. I believe this tradeoff is worth it in
this case, especially because these are very much not common nodes
in the first place.
3ef71cdb45
