Turns out, it was already almost correct. If you disregard \c and \M style escapes, only a single character is allowed to be escaped in a regex so most tests passed already.
There was also a mistake where the wrong value was constructed for the ast, this is now fixed.
One test fails because of this, but I'm fairly sure it is because of a parser bug. For `/\“/`, the backslash is supposed to be removed because it is a multibyte character. But tbh,
I don't entirely understand all the rules.
Fixes more than half of the remaining ast differences for rubocop tests
When parent scopes around an eval are forwarding parameters (like
*, **, &, or ...) we need to know that information when we are in
the parser. As such, we need to support passing that information
into the scopes option. In order to do this, unfortunately we need
a bunch of changes.
The scopes option was previously an array of array of strings.
These corresponded to the names of the locals in the parent scopes.
We still support this, but now additionally support passing in a
Prism::Scope instance at each index in the array. This Prism::Scope
class holds both the names of the locals as well as an array of
forwarding parameter names (symbols corresponding to the forwarding
parameters). There is convenience function on the Prism module that
creates a Prism::Scope object using Prism.scope.
In JavaScript, we now additionally support an object much the same
as the Ruby side. In Java, we now have a ParsingOptions.Scope class
that holds that information. In the dump APIs, these objects in all
3 languages will add an additional byte for the forwarding flags in
the middle of the scopes serialization.
All of this is in service of properly parsing the following code:
```ruby
def foo(*) = eval("bar(*)")
```
21abb6b7c4
When there were more actual tokens than expected tokens, the test would still pass.
Now it's possible to receive an assertion like this:
```
expected: []
actual: [:tNL, [nil, #<Parser::Source::Range comment_single.txt 8...9>]]
<[]> expected but was
<[:tNL, [nil, #<Parser::Source::Range comment_single.txt 8...9>]]>
```
e9e9a48e43
- Split static recipes to depend file.
- Modify makefile configurations in the block to `create_makefile`.
- Expand rust sources in extconf.rb instead of GNU make extension.
TODO: pass `CARGO_TARGET_DIR` without shell syntax.
This reverts the change made to this test case in commit a0e98d48c9
(Enhance TLS 1.3 support on LibreSSL 3.2/3.3, 2020-12-03).
Part of the test case was skipped on LibreSSL because LibreSSL 3.2.2
introduced a stricter check during creation of the extension. The check
was then relaxed in LibreSSL 3.4.0.
187b176ecd
[Bug #20972]
The `rb_str_new_freeze` was added in https://github.com/ruby/openssl/issues/452
to better handle concurrent use of a Socket, but SSL sockets can't be used
concurrently AFAIK, so we might as well just error cleanly.
By using `rb_str_locktmp` we can ensure attempts at concurrent write
will raise an error, be we avoid causing a copy of the bytes.
We also use the newer `String#append_as_bytes` method when available
to save on some more copies.
0d8c17aa85
Co-Authored-By: luke.gru@gmail.com
Ref: https://github.com/ruby/json/pull/718
The existing `Parser` interface is pretty bad, as it forces to
instantiate a new instance for each document.
Instead it's preferable to only take the config and do all the
initialization needed, and then keep the parsing state on the
stack on in ephemeral memory.
This refactor makes the `JSON::Coder` pull request much easier to
implement in a performant way.
c8d5236a92
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
In the past, bundler updated platform without normalized variable like arm64-darwin-23.
We ignored that update. But the current bundler uses arm64-darwin for that.
I think logger is only used to figure out which methods need to be made
noops in order to silence webrick during tests.
However, it seems possible to do the same using webrick's builtin logger
and the current method does not seem even correct since it's not
guaranteed that the logger gem and webrick's logger will use the same
methods.
Tests don't use it directly, so no need to specify it in our Gemfile.
I think it may have only been added because sinatra was not declaring
its dependency at the time.
parsing
(https://github.com/ruby/fiddle/pull/169)
GitHub: fix https://github.com/ruby/fiddle/pull/168
Struct parsing invokes "parse_ctype" on the whole member signature,
which fails if member type is "bool" due to plain string matching for
it. This change updates "bool" type matching to a regexp, so TYPE_BOOL
is correctly parsed for a whole signature like "bool toggle" as well as
just "bool".
---------
71607446d4
Co-authored-by: Sutou Kouhei <kou@cozmixng.org>
I think we have consistent behavior regardless of the version of git
being used, and I'd like to keep it like that so I think we can remove
this filter.
6a708128e9
