I see `Array.include?` as 2.4% runtime. Probably because of `LPAREN_CONVERSION_TOKEN_TYPES` but
the others will be faster as well.
Also remove some inline array checks. They are specifically optimized in Ruby since 3.4, but for now prism is for >= 2.7
ca9500a3fc
Temoprary backwards-compat code so that current users
don't break.
Eventually the Translation::Parser initializer should asser that the correct class is passed in.
66b0162b35
In a large application I profiled allocations while running `bundle
update` and found that this method was ~60% of allocations while
resolving (and Candidate#<=> is almost half of the total runtime).
This commit removes the array allocation in Candidate#<=> (and similar
methods since the implementations are so simple). The array is always
the same two elements so they can just be compared directly.
6a7c411ba7
If a custom rubygems source URI is long enough, Bundler may end up
raising an `ENAMETOOLONG` error and crash.
This commit fixes the problem by trimming the cache slug size to fit
usual OS requirements.
df40ff1e14
Co-authored-by: mbclu <mbclu@users.noreply.github.com>
Co-authored-by: martinemde <martinemde@users.noreply.github.com>
## Summary
`itblock` node is added to support the `it` block parameter syntax introduced in Ruby 3.4.
```console
$ ruby -Ilib -rprism -rprism/translation/parser34 -e 'buffer = Parser::Source::Buffer.new("path"); buffer.source = "proc { it }"; \
p Prism::Translation::Parser34.new.tokenize(buffer)[0]'
s(:itblock,
s(:send, nil, :proc), :it,
s(:lvar, :it))
```
This node design is similar to the `numblock` node, which was introduced for the numbered parameter syntax in Ruby 2.7.
```
$ ruby -Ilib -rprism -rprism/translation/parser34 -e 'buffer = Parser::Source::Buffer.new("path"); buffer.source = "proc { _1 }"; \
p Prism::Translation::Parser34.new.tokenize(buffer)[0]'
s(:numblock,
s(:send, nil, :proc), 1,
s(:lvar, :_1))
```
The difference is that while numbered parameters can have multiple parameters, the `it` block parameter syntax allows only a single parameter.
In Ruby 3.3, the conventional node prior to the `it` block parameter syntax is returned.
```console
$ ruby -Ilib -rprism -rprism/translation/parser33 -e 'buffer = Parser::Source::Buffer.new("path"); buffer.source = "proc { it }"; \
p Prism::Translation::Parser33.new.tokenize(buffer)[0]'
s(:block,
s(:send, nil, :proc),
s(:args),
s(:send, nil, :it))
```
## Development Note
The Parser gem does not yet support the `it` block parameter syntax. This is the first case where Prism's node design precedes that of the Parser gem.
When implementing https://github.com/whitequark/parser/issues/962, this node design will need to be taken into consideration.
c141e1420a
In mock testing for stdout, `StringIO.new` is sometimes used to redirect the output.
In such cases, the assignment is done with `$stdout = StringIO.new`, not the constant `STDOUT`.
e.g., https://github.com/rubocop/rubocop/blob/v1.71.1/lib/rubocop/rspec/shared_contexts.rb#L154-L164
After assigning `StringIO.new`, `$stdout.tty?` returns `false`,
allowing the standard output destination to be switched during test execution.
```ruby
STDOUT.tty? # => true
StringIO.new.tty? # => false
```
However, since `STDOUT.tty?` returns `true`, a failure occurred in environments
where the environment variables `RUBY_PAGER` or `PAGER` are set.
e.g., https://github.com/rubocop/rubocop/pull/13784
To address this, `STDOUT` has been updated to `$stdout` so that the result of `tty?` can be flexibly overridden.
A potential concern is that `$stdout`, unlike `STDOUT`,
does not always represent the standard output at the time the Ruby process started.
However, no concrete examples of issues related to this have been identified.
`STDOUT.tty?` is the logic of optparse introduced in https://github.com/ruby/optparse/pull/70.
This PR replaces `STDOUT` with `$stdout` throughout, based on the assumption
that `$stdout` is sufficient for use with optparse.
262cf6f9ac
Currently, some warning messages don't contain a `URI` like the following.
```ruby
warning: URI::ABS_URI is obsolete. Use RFC2396_PARSER.regexp[:ABS_URI] explicitly.
```
But, without `URI` prefix, the suggested value doesn't work.
So I think we should use a fully qualified name to avoid confusion.
428eb10e44
I want to add new node types to the parser translator, for example `itblock`. The bulk of the work is already done by prism itself. In the `parser`
builder, this would be a 5-line change at most but we don't control that here.
Instead, we can add our own builder and either overwrite the few methods we need,
or just inline the complete builder. I'm not sure yet which would be better.
`rubocop-ast` uses its own builder for `parser`. For this to correctly work, it must explicitly choose to extend the
prism builder and use it, same as it currently chooses to use a different parser when prism is used.
I'd like to enforce that the builder for prism extends its custom one since it will lead to
some pretty weird issues otherwise. But first, I'd like to change `rubocop-ast` to make use of this.
b080e608a8
This message is printed when running `bundle lock --add-platform`. This
command affects the lockfile, not the gemfile, and I think it's better
to use "You are adding" rather than "You added", because the addition is
happening during the current invocation (as opposed to other log
messages that talk about a change made to the Gemfile prior to running
the command).
aba1e55f5b
- ### Problem
Running `bundle doctor` warn about files that aren't writable.
This makes the output of `bundle doctor` very verbose for something
I believe isn't really an issue.
### Context
Rubygems keeps the files original permission at the time the gem
is packaged.
Many gem maintainers have decided that the permissions of the files
in their bundled would be 0444, this includes amongst others:
minitest, selenium, brakeman...
Any git gems that had a 0444 permissions at some point in its git
history would also be reported (as bundle doctor look in the
`cache/bundler/git/<gem>/object` path).
While it completely make sense to report when files aren't readable,
maybe it's worth questioning the usefulness of reporting files
that can't be written and what problem this causes to the user
(if any).
### Solution
Removed the check for unwritable file.
### Side note
I also tweaked the "No issues ..." message logic as it was doing
the opposite (reporting an issue when there is none and vice versa).
This wasn't caught in tests because as a stub on `Bundler.ui.info`
was missing.
9a426b9495
