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
https://github.com/ruby/prism/commit/b443cb1f60
Co-Authored-By: Kevin Newton <kddnewton@gmail.com>
Co-Authored-By: Jemma Issroff <jemmaissroff@gmail.com>
Even for singleton class definition such as `class << self` that
shares the same container with the outer scope, its visibility is
separated and set to `public` by default.
https://github.com/ruby/rdoc/commit/baf26363b9
Each singleton method definition of the form `def recv.method` has
visibility separate from the outer scope and is set to `public` by
default.
https://github.com/ruby/rdoc/commit/810913a7ea
(https://github.com/ruby/irb/pull/835)
* Remove unnecessary code from the exit command's implementation
1. The parameters of `IRB.irb_exit` were never used. But there are some
libraries seem to call it with arguments + it's declared on the top-level
IRB constant. So I changed the params to anonymous splat instead of removing them.
2. `Context#exit` was completely unnecessary as `IRB.irb_exit` doesn't use
the `@irb` instance it passes. And since it's (or should be treated as)
a private method, I simply removed it.
3. The `exit` command doesn't use the status argument it receives at all.
But to avoid raising errors on usages like `exit 1`, I changed the argument to
anonymous splat instead removing it.
* Make exit an actual command
* Update readme
https://github.com/ruby/irb/commit/452b543a65
`@locale` is set from `@locale_name` and loaded from `@locale_dir`
after `write_options`, and `RDoc::I18n::Locale` does not seem to
expected to be loaded.
https://github.com/ruby/rdoc/commit/fd610f7023
Otherwise, the path could be considered part of the host or port.
This is better than modifying the path to make it absolute when
a host or port is set. We could also raise for invalid paths
when a host or port is set using check_path, but that results
in weird errors, and won't catch issues (such as ftp allowing a
relative path).
Fixes [Bug #19916]
https://github.com/ruby/uri/commit/ac32aa005b
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.
https://github.com/ruby/prism/commit/d8c7e6bd10
`IPAddr.ntop` takes the binary representation of an IP address, whose
length should be 4 or 16 *bytes* (not characters/codepoints).
The current implementation accepts strings in any encoding, but for
some values in non-BINARY encoding, it fails proper length check and
raises an `AddressFamilyError`. Since passing strings in a multibyte
encoding has never worked correctly for years, this patch makes it an
explicit error with an `InvalidAddressError`.
Fixes: https://github.com/ruby/ipaddr/issues/56https://github.com/ruby/ipaddr/commit/a33fd14d4a
comptime_key is a Ruby object and the value is not valid in machine code.
This PR also implements `CMP r/m64, imm32 (Mod 01: [reg]+disp8)` that is
now needed for running mail.gem benchmark.
(https://github.com/ruby/irb/pull/817)
1. Because `IRB.rc_file` always generates an rc file name, even if the
file doesn't exist, we should check the file exists before trying to
load it.
2. If any type of errors occur while loading the rc file, we should
warn the user about it.
https://github.com/ruby/irb/commit/37ffdc6b19
Refactor vendoring to allow validating vendoring is reproducible
Helps ensure that unsuspecting diffs to the vendored code arent accidentally introduced
Previous attempt to use a full path when the running version is
different than the one that would be activated by default are different
was not correct.
This is because if this error happens in a `bundle exec` context, the
`Gem.loaded_specs` is cleared because we're in an exec'd process, so
will be always using a full path in these cases.
This alternative approach should do what I was expecting.
https://github.com/rubygems/rubygems/commit/e0bb8bf51b
It's the `Gem::Installer` below what installs executables, and the code
being deleted here is now actually creating a `gems/` folder in the root
of the source repo when running `ruby setup.rb`.
https://github.com/rubygems/rubygems/commit/0e69a8b0d6
For Ruby re-distributors, automatic user-install might be the right
default. Therefore printing warning about installing into user directory
is not always desirable. Let the default_user_install method be
customizable.
https://github.com/rubygems/rubygems/commit/2320dba544
This problem is quite specific to our dev environment, but I guess the
fix could be handy for other situations.
After merging a change to treat default gems as regular gems, I get this
when trying to run `rubocop` on our repo:
```
$ bin/rubocop --only Performance/RegexpMatch
Could not find json-2.6.3 in locally installed gems
Run `bundle install --gemfile /Users/deivid/code/rubygems/rubygems/tool/bundler/lint_gems.rb` to install missing gems.
```
However, when running the suggested command, nothing changes and I still
get the same error:
```
$ bundle install --gemfile /Users/deivid/code/rubygems/rubygems/tool/bundler/lint_gems.rb
Using ast 2.4.2
Using bundler 2.4.10
Using json 2.6.3
Using parallel 1.23.0
Using racc 1.7.1
Using parser 3.2.2.3
Using rainbow 3.1.1
Using regexp_parser 2.8.1
Using rexml 3.2.5
Using rubocop-ast 1.29.0
Using ruby-progressbar 1.13.0
Using unicode-display_width 2.4.2
Using rubocop 1.52.1
Using rubocop-performance 1.14.2
Bundle complete! 2 Gemfile dependencies, 14 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
$ bin/rubocop --only Performance/RegexpMatch
Could not find json-2.6.3 in locally installed gems
Run `bundle install --gemfile /Users/deivid/code/rubygems/rubygems/tool/bundler/lint_gems.rb` to install missing gems.
```
The problem is that our `bin/rubocop` script uses the development
version of Bundler (which has the change causing the problem), but the
advice recommands the default version of Bundler, which does not yet
have the change.
This commit changes the advice to recommend to use the same version of
Bundler that run into the problem in the first place.
So in the above situation you now get:
```
$ bin/rubocop --only Performance/RegexpMatch
Could not find json-2.6.3 in locally installed gems
Run `/Users/deivid/code/rubygems/rubygems/bundler/exe/bundle install --gemfile /Users/deivid/code/rubygems/rubygems/tool/bundler/lint_gems.rb` to install missing gems.
```
And running that fixes the problem:
```
$ /Users/deivid//rubygems/rubygems/bundler/exe/bundle install --gemfile /Users/deivid/code/rubygems/rubygems/tool/bundler/lint_gems.rb
Fetching gem metadata from https://rubygems.org/.........
Fetching json 2.6.3
Installing json 2.6.3 with native extensions
Bundle complete! 2 Gemfile dependencies, 14 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
```
https://github.com/rubygems/rubygems/commit/10a9588c6d
If a gem is specified in the Gemfile (or resolved as a transitive
dependency), it's always resolved from remote/installed sources. Default
gems are only used as a fallback for gems not included in the bundle.
I believe this leads to more consistent behavior and more portable apps,
since all gems will be installed to the configured bundle path,
regardless of whether they are default gems or not.
https://github.com/rubygems/rubygems/commit/091b4fcf2b
This makes bundler consistent with all other gems, and makes the default
installation of Bundler in the release package look like any other
bundler installation.
Before (on preview3, for example), Bundler executable is installed at:
lib/ruby/gems/3.3.0+0/gems/bundler-2.5.0.dev/libexec/bundle
Now it's installed in the standard location:
lib/ruby/gems/3.3.0+0/gems/bundler-2.5.0.dev/exe/bundle
The `options[:user_install]` might have three states:
* `true`: `--user-install`
* `false`: `--no-user-install` and
* `nil`: option was not specified
However, this had not been respected previously and the `false` and `nil`
were treated the same. This could lead to auto user installation despite
`--no-user-install` being specified on the command line.
Fixes https://github.com/rubygems/rubygems/pull/7237https://github.com/rubygems/rubygems/commit/9281545474
Hiroshi SHIBATA
Kenta Murata
Cody Cutrer
Brave Hager
Aaron Patterson
Nobuyoshi Nakada
Kevin Newton
Mark Young
Avdi Grimm
Stan Lo
BurdetteLamar
Jeremy Evans
Martin Emde
Takashi Kokubun
tomoya ishida
hyuraku
Alexander Momchilov
Blake Imsland
David Rodríguez
Earlopain
Luke Randall
Kasumi Hanazuki
Sutou Kouhei
Akinori MUSHA
Samuel Giddins
hogelog
ima1zumi
Vít Ondruch
Drew Stevenson
Akira Matsuda