This batch file used `nmake` on the old `command.com` to extract the
parent directory name of this file and to get around the command line
argument length limit. However, Windows 9X support as a build host
ended over a decade ago, and this file now utilizes the functionality
of `cmd.exe` already.
Ripper exposes Ripper::Lexer:State in its output, which is a bit of a problem. To make this work, I basically copy-pasted the implementation.
I'm unsure if that is acceptable and added a test to make sure that these values never go out of sync.
I don't imagine them changing often, prism maps them 1:1 for its own usage.
This also fixed the shim by accident. `Ripper.lex` went to `Translation::Ripper.lex` when it should have been the original. Removing the need for the original resolves that issue.
https://github.com/ruby/prism/commit/2c0bea076d
If the baseruby is explicitly specified, fail because the option is
not accepted if it does not meet the requirements. If the option is
not specified, just display the warning and continue, in the hope that
it is not needed.
Follow up GH-15809
When requiring a file like "benchmark/ips", the warning system would
incorrectly warn about the "benchmark" gem not being a default gem,
even when the user has "benchmark-ips" (a separate third-party gem)
in their Gemfile.
The fix checks if a hyphenated version of the require path exists in
the bundle specs before issuing a warning. For example, requiring
"benchmark/ips" now checks for both "benchmark" and "benchmark-ips"
in the Gemfile.
[Bug #21828]
This test obtains an available port number by calling `TCPServer.new`,
then closes it and passes the same port number as `local_port` to `TCPSocket.new`.
However, `TCPSocket.new` could occasionally fail with `Errno::EADDRINUSE`
at the bind(2) step.
I believe this happens when tests are run in parallel and another process
on the same host happens to bind the same port in the short window between
closing the `TCPServer` and calling `TCPSocket.new`.
To address this race condition, the test now retries with a newly selected
available port when such a conflict occurs.
I stumbled across a bundler bug that had me scratching my head for
awhile, because I hadn't experienced it before.
In some cases when changing the source in a gemfile from a
`Source::Gemspec` to either a `Source::Path` or `Source::Git` only the
parent gem will have it's gem replaced and updated and the child
components will retain the original version. This only happens if the gem
version of the `Source::Gemspec` and `Source::Git` are the same. It also
requires another gem to share a dependency with the one being updated.
For example if I have the following gemfile:
```
gem "rails", "~> 8.1.1"
gem "propshaft"
```
Rails has a component called `actionpack` which `propshaft` depends on.
If I change `rails` to point at a git source (or path source), only the
path for `rails` gets updated:
```
gem "rails", github: "rails/rails", branch: "8-1-stable"
gem "propshaft"
```
Because `actionpack` is a dependency of `propshaft`, it will remain in
the rubygems source in the lock file WHILE the other gems are correctly
pointing to the git source.
Gemfile.lock:
```
GIT
remote: https://github.com/rails/rails.git
revision: https://github.com/ruby/rubygems/commit/9439f463e0ef
branch: 8-1-stable
specs:
actioncable (8.1.1)
...
actionmailbox (8.1.1)
...
actionmailer (8.1.1)
...
actiontext (8.1.1)
...
activejob (8.1.1)
...
activemodel (8.1.1)
...
activerecord (8.1.1)
...
activestorage (8.1.1)
...
rails (8.1.1)
...
railties (8.1.1)
...
GEM
remote: https://rubygems.org/
specs:
action_text-trix (2.1.15)
railties
actionpack (8.1.1) <===== incorrectly left in Rubygems source
...
```
The gemfile will contain `actionpack` in the rubygems source, but will
be missing in the git source so the path will be incorrect. A bundle
show on Rails will point to the correct place:
```
$ bundle show rails
/Users/eileencodes/.gem/ruby/3.4.4/bundler/gems/rails-9439f463e0ef
```
but a bundle show on actionpack will be incorrect:
```
$ bundle show actionpack
/Users/eileencodes/.gem/ruby/3.4.4/gems/actionpack-8.1.1
```
This bug requires the following to reproduce:
1) A gem like Rails that contains components that are released as their
own standalone gem is added to the gemfile pointing to rubygems
2) A second gem is added that depends on one of the gems in the first
gem (like propshaft does on actionpack)
3) The Rails gem is updated to use a git source, pointing to the same
version that is being used by rubygems (ie 8.1.1)
4) `bundle` will only update the path for Rails component gems if no
other gem depends on it.
This incorrectly leaves Rails (or any gem like it) using two different
codepaths / gem source code.
https://github.com/ruby/rubygems/commit/dff76ba4f6
Add `rustc_flags` option for configure that appends to RUSTC_FLAGS
flags used when compiling with rustc for customizable build flags.
It appends to existing defaults in RUSTC_FLAGS.
Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>
Previously: In #9218 a reproduction is shared where running `bundle clean` using a binstub (`bin/bundle`) results in bundler removing itself. This results in Ruby falling back to its default bundler version. This behavior seems to be present for as long as there has been a default version of bundler (Ruby 2.6+).
Now: Bundler will explicitly add its current version number to the specs to be preserved. This prevents `bundle clean` from removing the current bundler version.
close https://github.com/ruby/rubygems/pull/9218https://github.com/ruby/rubygems/commit/e3f0167ae4
When sleeping with `sleep`, currently the main thread can get woken up from sigchld
from any thread (subprocess exited). The timer thread wakes up the main thread when this
happens, as it checks for signals. The main thread then executes the ruby sigchld handler
if one is registered and is supposed to go back to sleep immediately. This is not ideal but
it's the way it's worked for a while. In commit 8d8159e7d8 I added writes to `th->status`
before and after `wait_running_turn` in `thread_sched_to_waiting_until_wakeup`, which is
called from `sleep`. This is usually the right way to set the thread's status, but `sleep`
is an exception because the writes to `th->status` are done in `sleep_forever`. There's a
loop that checks `th->status` in `sleep_forever`. When the main thread got woken up from
sigchld it saw the changed `th->status` and continued to run the main thread instead of
going back to sleep.
The following script shows the error. It was returning instead of sleeping forever.
```ruby
t = Thread.new do
sleep 0.3
`echo hello` # Spawns subprocess
puts "Subprocess exited"
end
puts "Main thread sleeping..."
result = sleep # Should block forever
puts "sleep returned: #{result.inspect}"
```
Fixes [Bug #21812]
