| Age | Commit message (Collapse) | Author |
|
The with and without flags accepts both comma and space separated values.
https://github.com/rubygems/rubygems/commit/b6149f61e3
|
|
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.
https://github.com/rubygems/rubygems/commit/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.
https://github.com/ruby/prism/commit/c141e1420a
|
|
https://github.com/ruby/optparse/commit/f4d64b0b17
|
|
https://github.com/ruby/optparse/commit/83e8c23d68
|
|
If the original value of LESS ends with an option starting with "--",
simply appending "Fe" would result in an invalid option string.
https://github.com/ruby/optparse/commit/30571f91d3
|
|
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.
https://github.com/ruby/optparse/commit/262cf6f9ac
|
|
Fix https://github.com/ruby/optparse/pull/80
https://github.com/ruby/optparse/commit/050a87d029
|
|
https://github.com/ruby/optparse/commit/71e2b31824
|
|
https://github.com/ruby/optparse/commit/d7dec6808f
|
|
backqoutes
https://github.com/ruby/optparse/commit/5e71a70cb5
|
|
https://github.com/rubygems/rubygems/commit/369f9b9311
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
only the '.git' directory is present. This recovers cases where a git-sourced install can be left in a partially installed state.
https://github.com/rubygems/rubygems/commit/d132b7008d
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
https://github.com/rubygems/rubygems/commit/ba5a62fd04
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
https://github.com/rubygems/rubygems/commit/9691097036
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
Command line arguments are strings, convert enum list elements to
strings to match.
https://github.com/ruby/optparse/commit/c5ec052efc
|
|
https://github.com/ruby/optparse/commit/a3f1029815
|
|
Make `rdoc .` and `rake rdoc` consistent.
https://github.com/ruby/optparse/commit/61b4ea0704
|
|
https://github.com/rubygems/rubygems/commit/3b4934fb69
Notes:
Merged: https://github.com/ruby/ruby/pull/12840
|
|
option
https://github.com/rubygems/rubygems/commit/c258e45b44
Notes:
Merged: https://github.com/ruby/ruby/pull/12840
|
|
https://github.com/rubygems/rubygems/commit/591d2c0503
Notes:
Merged: https://github.com/ruby/ruby/pull/12840
|
|
https://github.com/rubygems/rubygems/commit/176dc7421c
Notes:
Merged: https://github.com/ruby/ruby/pull/12840
|
|
https://github.com/rubygems/rubygems/commit/fafb9ae090
|
|
https://github.com/ruby/cgi/commit/ab84b7fe66
|
|
https://github.com/ruby/cgi/commit/8e6fb1041b
|
|
It has been over a year since the release, so let's stop MD5ing everything
https://github.com/rubygems/rubygems/commit/29ef4ca30b
|
|
If we fail to write the lockfile, give a better error.
https://github.com/rubygems/rubygems/commit/81a08d6eda
|
|
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.
https://github.com/ruby/uri/commit/428eb10e44
|
|
This was removed by #9.
https://github.com/ruby/uri/commit/fec924238f
|
|
https://github.com/ruby/cgi/commit/cd1eb08076
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
|
|
https://github.com/ruby/cgi/commit/9907b76dad
Co-authored-by: "Yusuke Endoh" <mame@ruby-lang.org>
|
|
https://github.com/ruby/uri/commit/3213f4a0f8
|
|
https://hackerone.com/reports/2957667
https://github.com/ruby/uri/commit/2789182478
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
|
|
https://github.com/ruby/uri/commit/3675494839
|
|
https://github.com/ruby/cgi/commit/3f5b4ed9e9
|
|
This restores the missing method comments in https://github.com/ruby/prism/pull/3479.
https://github.com/ruby/prism/commit/78b8f67dee
|
|
Caused by https://github.com/ruby/prism/pull/3478 and https://github.com/ruby/prism/pull/3443
I also made the builder reference more explicit to clearly distinquish
between `::Parser` and `Prism::Translation::Parser`
https://github.com/ruby/prism/commit/d52aaa75b6
|
|
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.
https://github.com/ruby/prism/commit/b080e608a8
|
|
Follow-up to https://github.com/Shopify/ruby-lsp/pull/1849.
This is an extension of `Prism::Translation::Parser` to implement https://github.com/Shopify/ruby-lsp/pull/1849.
It is based on the comments in https://github.com/Shopify/ruby-lsp/pull/1849#pullrequestreview-1966020868,
but also adds a default argument for delegation to `Parser::Base` super class.
Using this API, https://github.com/rubocop/rubocop-ast/pull/359 has been implemented in RuboCop AST.
As detailed in https://github.com/rubocop/rubocop-ast/pull/359, this change is expected to improve performance by 1.3x
for some source code.
Achieving a 1.3x speedup with such this simple modification is a significant improvement for Ruby LSP and its users.
https://github.com/ruby/prism/commit/925725291c
|
|
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).
https://github.com/rubygems/rubygems/commit/aba1e55f5b
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
And make it consistent with platform additions.
https://github.com/rubygems/rubygems/commit/64342ae404
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
not in lockfile
Current it says "you added a new platform to your gemfile", but that's
not actually the case here.
https://github.com/rubygems/rubygems/commit/1e39527a38
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
aren't writable:
- ### 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.
https://github.com/rubygems/rubygems/commit/9a426b9495
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
(https://github.com/ruby/pp/pull/38)
https://github.com/ruby/pp/commit/5b5d483ac2
|
|
https://github.com/ruby/cgi/commit/defbdf9a30
|
|
protected folders
As long as there's nothing new to install and gems are already there.
If not, give a meaningful error about what happened.
This was how things already worked until
https://github.com/rubygems/rubygems/commit/345ec45f5a87, so this commit partially
reverts that change.
https://github.com/rubygems/rubygems/commit/794b0ecb39
|
|
https://github.com/rubygems/rubygems/commit/677e17aa2e
|
|
being created
https://github.com/rubygems/rubygems/commit/f2f2ac9680
|
|
feature now
https://github.com/rubygems/rubygems/commit/b29f8d6a37
|
|
When working with our repository on JRuby locally, I get the following
changes when running `bin/rake setup` in all of our lockfiles
```diff
diff --git a/tool/bundler/dev_gems.rb.lock b/tool/bundler/dev_gems.rb.lock
index https://github.com/rubygems/rubygems/commit/362bf25690d..https://github.com/rubygems/rubygems/commit/74550b2a408 100644
--- a/tool/bundler/dev_gems.rb.lock
+++ b/tool/bundler/dev_gems.rb.lock
@@ -66,6 +66,7 @@ PLATFORMS
java
ruby
universal-java
+ universal-java-22
x64-mingw-ucrt
x86-linux
x86_64-darwin
```
This is inconvenient, so I applied the same strategy we already use on
non JRuby implementations to not add the current platform to the
lockfile if a less specific platform is already there.
https://github.com/rubygems/rubygems/commit/812b9cd1e8
|