| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
|
|
|
|
| |
Also install external libraries only, extract-gems does not work
unless base ruby is available.
|
| |
|
|
|
|
| |
Fixnum and Bignum have been unified to Integer already.
|
| |
|
| |
|
|
|
|
| |
They are no longer needed since ruby 2.0.
|
|
|
|
| |
There's better tools for this job.
|
| |
|
|
|
|
| |
No other files in the repo include this.
|
| |
|
|
|
|
| |
To make rubygems code style consistent with bundler.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In `ruby-head` (where system rubygems already has the `XDG` standard
implementation), some tests currently depend on the presence of a
`~/.gem` folder in the home of the user that runs the tests. If that
file is present, tests pass, otherwise they don't.
For example, the following passes if you have a `~/.gem` folder but
fails otherwise with:
```
$ rake TESTOPTS="--name=/TestGemCommandsGenerateIndexCommand#test_execute$\|TestGemCommandsUpdateCommand#test_execute_user_install/ -v"
Run options: "--name=/TestGemCommandsGenerateIndexCommand#test_execute$|TestGemCommandsUpdateCommand#test_execute_user_install/" -v --seed 17318
# Running:
TestGemCommandsGenerateIndexCommand#test_execute = 0.02 s = .
TestGemCommandsUpdateCommand#test_execute_user_install = /rubygems/test/rubygems/test_gem_commands_update_command.rb:412: warning: instance variable @user_install not initialized
0.04 s = F
Finished in 0.095337s, 20.9783 runs/s, 20.9783 assertions/s.
1) Failure:
TestGemCommandsUpdateCommand#test_execute_user_install [/rubygems/test/rubygems/test_gem_commands_update_command.rb:414]:
user_install must be set on the installer
2 runs, 2 assertions, 1 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1)
Tasks: TOP => default => test
(See full trace by running task with --trace)
```
This is because the very initial `require` of the default `did_you_mean`
gem that ruby does on startup runs _before_ the global `setup` hook of
our tests run. During this require `Gem.data_home` and its value is
memoized to a path in the real users home (not the fake user's home that
our tests setup, since that code hasn't run yet). Then that memoized
value is used when looking for the default folders to look for gems, and
since there's no `~/.gem` folder, its value is actually used as part of
the `Gem.user_dir` folder in `Gem::Specification.dirs` (this is how
we've approached backwards compatibility for the `XDG` feature). That
means dummy test gems with the `--user-install` flag are installed to
global, real locations and everything is messed up.
This commit fixes the issue by resetting the `Gem.data_home` value in
case it has already been memoized.
|
|
|
|
| |
This reverts commit ac2c07e98373bb62be618001c897fa9d5809d8a4.
|
|
|
|
| |
This reverts commit ceacb06311cf150cd3682b277bbe6cf7e7bbbc30.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
... based on CRC32 of names of the test suites.
Formerly, `make test-all` randomized the order of the test suites by
using `Array#shuffle`. It also shows `--seed N` to reproduce the order,
but it was not reproducible when a suite set is different.
This change sorts the suites by CRC32 hash of the suite names with a
salt generated by the seed.
|
|
|
|
|
|
| |
I'm guessing the commands under ruby-core setup are very long, so the
title gets truncated. Use a shorter title, since the test doesn't really
care.
|
|
|
|
|
|
|
|
|
| |
The `gem_command` helper was failing to require `support/hax.rb`, which
takes care of making sure rubygems actually picks up the right `ruby`
executable under ruby-core setup (`ENV["RUBY"]`). This caused binstubs
to be generated with a wrong shebang, and that caused `bundle exec` to
not work. The error message was pretty confusing though due to
https://bugs.ruby-lang.org/issues/16952.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try to fix 404 error on mswinci.
https://rubyci.org/logs/mswinci.japaneast.cloudapp.azure.com/vc12-x64/ruby-master/log/20200614T225859Z.fail.html.gz
```
1) Failure:
WEBrick::TestFileHandler#test_cjk_in_path [D:/tmp/mswin-build20200615-24932-11ykstf/ruby/test/webrick/utils.rb:72]:
exceptions on 2 threads:
webrick log start:
[2020-06-15 09:48:29] ERROR `/あ.txt' not found.
webrick log end.
<"200"> expected but was
<"404">.
---
<[]> expected but was
<["[2020-06-15 09:48:29] ERROR `/\xE3\x81\x82.txt' not found.\n"]>.
```
|
|
|
|
|
|
|
|
| |
failure on TestFTP.
When we skip a test, the place to hang (long wait for compilation)
just moves to another test and it doesn't seem to finish.
http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/3003055
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
with Ripper.
a3e6f52c17061f012c4e638b3343b57752ed7603 introduced __builtin_cexpr! and
__builtin_cstmt!, but nobody has used them and then they broke on
79292b30884ebcd8be028a7f3c9ccafd7759f2ae by undefined `params`.
This patch fixes the undefined `params`, but still we're not using them
yet.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Timeout-based test often fails with --jit-wait as a false positive.
Like other tests in the TestFTP, let me skip this as well.
http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/3001181
http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/3000134
http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/2999923
http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/2998857
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Methods:
#join
#inspect/#to_s
#to_a
|
| |
|
|
|
|
| |
Scripts to run the interpreter via debugger.
|
|
|
|
|
|
|
|
|
|
|
| |
Methods:
#insert
#each
#each_index
#reverse_each
#length
#empty?
|
| |
|
|
|
|
|
|
|
|
|
| |
The code assumed that /usr/share/dict/words did not use mixed
case, and it does at least on a few operating systems.
From CryptoRAT (Luke Elliot)
Fixes [Bug #16957]
|
|
|
|
|
|
| |
This reverts commit 7cddb844e6d51f954c6669341b9cc656bd7d3492,
because the test of rake 13.0.1 is depending on the previous
behavior.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`FileUtils#install` methed raises an unexpected `TypeError`, when
called with `mode:` option which has `"X"`.
```
$ ruby -rfileutils -e 'FileUtils.install("tmp/a", "tmp/b", mode: "o+X")'
/opt/local/lib/ruby/2.7.0/fileutils.rb:942:in `directory?': no implicit conversion of File::Stat into String (TypeError)
from /opt/local/lib/ruby/2.7.0/fileutils.rb:942:in `block (3 levels) in symbolic_modes_to_i'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:933:in `each_char'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:933:in `each'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:933:in `inject'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:933:in `block (2 levels) in symbolic_modes_to_i'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:931:in `each'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:931:in `each_slice'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:931:in `block in symbolic_modes_to_i'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:926:in `each'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:926:in `inject'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:926:in `symbolic_modes_to_i'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:973:in `fu_mode'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:883:in `block in install'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:1588:in `block in fu_each_src_dest'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:1604:in `fu_each_src_dest0'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:1586:in `fu_each_src_dest'
from /opt/local/lib/ruby/2.7.0/fileutils.rb:877:in `install'
from -e:1:in `<main>'
```
In spite of that `symbolic_modes_to_i` considers the `File::Stat`
`path` case at the beginning, in `"X"` case, `path` is passed to
`FileTest.directory?` method which requires a `String`. In such
case, the mode in `path` should be examined instead.
https://github.com/ruby/fileutils/commit/af675af6b2
|
|
|
|
|
|
|
|
|
| |
Verbose output is not error output, and should be sent to
stdout and not stderr.
Fixes Ruby bug 4436
https://github.com/ruby/fileutils/commit/563a383025
|
|
|
|
|
|
|
|
| |
We observed test failures on test_latest_gc_info with random
order CI.
http://ci.rvm.jp/results/trunk-random1@phosphorus-docker/2998078l0ll
To solve it, use a pre-allocated hash object and rehearsal.
|
| |
|
|
|
|
| |
Maybe 182ae1407b3f6597cdbf6872f788c1ed3aa22a35 missed it.
|
|
|
|
| |
Fixes [Bug #15834]
|