- Similar change than 29a1be0008,
keep a single source of truth where we store the platform.
The only change worth highlighing is the platform "maglev".
It was not part of the supported platform of dependencies,
so calling `gem 'foo', plaftorm: 'maglev'` would not work.
However, it was supposed to according to 45ec86e2e5.
That's why it was possible to do `Bundler.current_ruby.maglev?` or
`Bundler.current_ruby.maglev_30?`.
I didn't change the current behaviour and maglev is not supported,
though I kept the `*maglev` methods as I believe CurrentRuby is
public API.
29e219ebcf
- We keep 2 list of supported ruby versions and each time a new ruby
version is released we need to maintain both list. Forgetting
to update one would prevent users from adding gem for a specific
plaftorm (i.e. 7cd19d824d and 5462322f8f).
Extracted the list from the Dependency class and moved it to the
CurrentRuby class (which I believe was originally added for that
reason).
a91edd6c1f
We need to move platform monkeypatching to happen earlier because
otherwise `Bundler::GemHelpers` will use the constants before they have
actually been defined.
086c3438dc
launch
(https://github.com/ruby/irb/pull/1040)
* Quickly show inspect preview even if pretty_print takes too much time
* Show a message "Inspecting..." while generating pretty_print content
* Update inspecting message
Co-authored-by: Stan Lo <stan001212@gmail.com>
* Update rendering test for preparing inspect message
* Don't show preview if pretty_print does not take time
---------
03c36586e6
Co-authored-by: Stan Lo <stan001212@gmail.com>
`builder.pair_label` is no good since it makes use of variables that the parser gem encountered.
Since the prism translator doesn't keep proper track of that information, the following code interprets
the implicit value as a local variable, even though it is not in scope:
```rb
def foo
bar = 123
end
{ bar: }
```
bbeb5b083a
These changes were included when adding bundler plugin hooks for
`Bundler.require`, but they seem completely unrelated to that feature,
and have caused several issues.
8d56551dcf
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
