not only when !w but also when w == WAITPID_LOCK_ONLY.
See also: f7c0cc3692 and a226434206.
We thought this change was an oversight in the latter commit.
Without this change, the test fails like:
$ make test-all TESTS="../test/ruby/test_process.rb -n test_exec_failure_leaves_no_child" RUN_OPTS="--jit"
...
1) Failure:
TestProcess#test_exec_failure_leaves_no_child [/home/k0kubun/src/github.com/ruby/ruby/test/ruby/test_process.rb:2493]:
Expected [[26799, #<Process::Status: pid 26799 exit 127>]] to be empty.
Co-Authored-By: Yusuke Endoh <mame@ruby-lang.org>
The rationale is that:
* The change has caused realworld issues. See for example
https://github.com/ruby/did_you_mean/issues/117 and specifically [this
comment](https://github.com/ruby/did_you_mean/issues/117#issuecomment-482733159)
for a great explanation of the issue it caused for `did_you_mean`.
* The change also causes problems for our development workflows. For
example, because of it, our `bundler` specs cannot currently be run with
`bin/rake` and we have to use `bin/rspec` or `bin/parallel_spec`
directly. The explanation for this is:
- Our specs install test dependencies to `tmp` before running specs.
- `rake` is one of these test dependencies.
- Before installing each test dependency, we check whether it has
matching installed specs: 2bbcdcde08/bundler/spec/support/rubygems_ext.rb (L109-L114).
- Normally, if `rake` has not yet been installed to `tmp`, this check
fails and `rake` is installed, but since the loaded specs are now
added to `Gem::Specification.stubs` and `rake`'s specification _is_
loaded because we're running through `bin/rake`, the check incorrectly
assumes that `rake` is already installed to `tmp` and skips
installation.
- At a later point the specs check whether `rake` is actually
installed and fail if it's not: 2bbcdcde08/bundler/spec/support/builders.rb (L372-L383)
Essentially, both of the issues are the same. If at runtime we change
the location of gems, we'll _want_ to not consider loaded specifications
when dealing with the new gem location, because the loaded
specifications have not been loaded from there. Loaded specifications is
something different from installed stub specifications and those should
not be mixed.
The PR still seemed to have fixed an issue, so I did my archaeology job
and investigated the original issue to double check if reverting is ok.
The logs for the original error can be found here:
https://ci.appveyor.com/project/rubygems/rubygems/build/1172/job/ogubyucpljcv22ux.
So I installed ruby 2.4.4, checked out the commit reference before the
offending PR, and the exact error reproduced. 🎉
```
$ rake test
/home/deivid/Code/rubygems/lib/rubygems/resolver.rb:231:in `search_for': Unable to resolve dependency: user requested 'bundler (= 1.16.2)' (Gem::UnsatisfiableDependencyError)
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:283:in `block in sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `each'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `sort_by'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `with_index'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:277:in `sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/delegates/specification_provider.rb:52:in `block in sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/delegates/specification_provider.rb:69:in `with_no_such_dependency_error_handling'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/delegates/specification_provider.rb:51:in `sort_dependencies'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:165:in `initial_state'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:106:in `start_resolution'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:64:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/resolver/molinillo/lib/molinillo/resolver.rb:42:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/resolver.rb:188:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/request_set.rb:396:in `resolve'
from /home/deivid/Code/rubygems/lib/rubygems/request_set.rb:408:in `resolve_current'
from /home/deivid/Code/rubygems/lib/rubygems.rb:243:in `finish_resolve'
from /home/deivid/Code/rubygems/lib/rubygems/rdoc.rb:13:in `<top (required)>'
from /home/deivid/Code/rubygems/lib/rubygems/core_ext/kernel_require.rb:54:in `require'
from /home/deivid/Code/rubygems/lib/rubygems/core_ext/kernel_require.rb:54:in `require'
from /home/deivid/Code/rubygems/lib/rubygems/test_case.rb:1563:in `<top (required)>'
from /home/deivid/Code/rubygems/test/rubygems/test_bundled_ca.rb:2:in `require'
from /home/deivid/Code/rubygems/test/rubygems/test_bundled_ca.rb:2:in `<top (required)>'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:15:in `require'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:15:in `block in <main>'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:4:in `select'
from /home/deivid/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb:4:in `<main>'
rake aborted!
Command failed with status (1)
Tasks: TOP => test
```
Now the explanation of the error:
* Rubygems base `TestCase` class requires `bundler` because some tests
use `bundler`:
2bbcdcde08/lib/rubygems/test_case.rb (L26)
* That `require` (our custom rubygems require) would activate the
default bundler spec (1.16.1 for ruby 2.4.4) but then overwrite it with
a 1.16.2 version (the locally provided bundler those days) due to [this
old
hack](9f7bf0ac3a/lib/bundler/version.rb (L7-L23)).
* Rubygems base `TestCase` class requires `rubygems/rdoc`:
2bbcdcde08/lib/rubygems/test_case.rb (L1536)
* And that file ends up calling `Gem.finish_resolve`:
2bbcdcde08/lib/rubygems/rdoc.rb (L13)
* `Gem.finish_resolve` adds the currently loaded specs to the
resolution:
2bbcdcde08/lib/rubygems.rb (L235)
* That means it would try to resolve bundler 1.16.2, but no
specification for that version was installed since the default was
1.16.1. That explains why upgrading to rubygems 2.7.7 fixed the issue,
since it provided bundler 1.16.2 by default so there was not bundler
version discrepancy.
After understanding the error, I conclude that:
* Only this part of the original patch was actually needed to resolve
the error, not any of the changes in `Gem::Specification.stubs` and
`Gem::Specification.stubs_for`:
```diff
diff --git a/lib/rubygems/test_case.rb b/lib/rubygems/test_case.rb
index f1cd3d274c..92c848e870 100644
--- a/lib/rubygems/test_case.rb
+++ b/lib/rubygems/test_case.rb
@@ -13,6 +13,15 @@ else
require 'rubygems'
end
+# If bundler gemspec exists, add to stubs
+bundler_gemspec = File.expand_path("../../../bundler/bundler.gemspec", __FILE__)
+if File.exist?(bundler_gemspec)
+ Gem::Specification.dirs.unshift File.dirname(bundler_gemspec)
+ Gem::Specification.class_variable_set :@@stubs, nil
+ Gem::Specification.stubs
+ Gem::Specification.dirs.shift
+end
+
begin
gem 'minitest'
rescue Gem::LoadError
```
So, I propose to revert adding loaded specification to
`Gem::Specification.stubs` and `Gem::Specification.stubs_for` because I
think it's safe, it fixes the issues caused by their addition, and it
simplifies `Gem::Specification` code, which is already complicated
enough.
https://github.com/rubygems/rubygems/commit/5269cd617c
Originally, the call to `.stubs_for` allowed to incrementally populate
the `@@stubs_by_name` (especially see the `"#{name}-*.gemspec"` pattern
in 4fa03bb7aac9f25f44394e818433fdda9962ae8d). Now it looks like it
expects that all stubs are loaded, but the `.stubs_for` still matches
the .gemspec files by the `name` pattern:
6d45e0f7ac/lib/rubygems/specification.rb (L845)
I think this was done by mistake incrementally by PR #1239 and
4cee8ca9199ac7b3ab8647e0b78615f55d3eb02b. I think the best option is to
get back to the original implementation, to let RubyGems incrementally
populate the array. Other option would be to replace the logic in
`.stub_for` by call to `.stubs`, but the means the performance
improvement from the original commit was lost.
https://github.com/rubygems/rubygems/commit/4d0e18185a
I believe these are most certainly due to a problem outside of rubygems.
I'm skipping these at least until webrick officially supports jruby
(defining "officially" as "webrick's CI passes on jruby").
https://github.com/rubygems/rubygems/commit/4fca025358
This requirement was introduced 14 years ago in
7ce7039b390440754954df5efea619e9f57ef823, and I don't think it's
necessary anymore. I made several tests introducing UTF-8 characters in
gemspec files and generating indexes out of them, and couldn't find any
issues. Gemspecs are read with UTF-8 encoding these days.
In ruby 2.7.0, there's a slight change in bundler's default gemspec file
where the executable folder of the bundler gem is `libexec` instead of
`exe`. I made that change in https://github.com/ruby/ruby/pull/2380 to
try to simplify the integration of the `bundler` gem with upstream,
minimizing the number of changes that need to be made to the gemspec to
adapt to the structure of ruby-core.
That worked ok, expected for this issue. The new name of the folder
including the executable files uncovered a bug in rubygems, which is the
following:
* In order to be able to use newer versions of default gems, `rubygems`
ships with a customized `require` that has knowledge about which files
belong to which default gem. If one of these files is required,
`rubygems` will detect that and activate its gem mechanism to choose the
newest version of the corresponding default gem present in the system
(unless a different version has already been activated). It's this part
of the custom require:
ea3e6f194d/lib/rubygems/core_ext/kernel_require.rb (L77-L85)
* In order to do that, `rubygems` registers a map of default gems and
their files when it is first required:
ea3e6f194d/lib/rubygems.rb (L1247-L1276)
As explained in the method's header, two types of default gem
specifications are supported. One of the formats is the style used by
some ruby-core gemspec files, where paths inside the `spec.files` array
don't include the `spec.require_paths` part. So in this "old style", if
a gem ships with a `lib/bundler.rb` file, it will be registered in this
array as `spec.files = ["bundler.rb"]`, not as `spec.files =
["lib/bundler.rb"]`. The `Gem.register_default_spec` method "detects"
this style by making sure that none of the files in the `spec.files`
array start with any of the `spec.require_paths`.
* Since in ruby 2.7 the default specification file of the `bundler` gem
includes a `libexec/bundle` file, this check would no longer work
correctly, because even though the specification file is still "old
style", it has one registered file which starts with "lib", one of the
"require paths" of the gem.
* This means that the gem is incorrectly detected as "new style", but
since none of the paths start with "lib/", no files are actually
registered, so the gem is not being considered a default gem, and thus
the default version is always used with no possibility of being
"upgraded".
The fix of the problem is simple: check that no files start with `lib/`
(or any other require paths), instead of with "lib" which doesn't
exclude other potential "non requirable folder" starting with lib, like
in the `bundler` case.
https://github.com/rubygems/rubygems/commit/94df740c2b
`site_dir`, or `vendor_dir`, is the location where the default version
of bundler & rubygems gets installed. These folders are placed directly
in the LOAD_PATH, so they cannot hold any nested gem directory
structure. So a single copy of either rubygems or bundler can be placed
in these folders.
What the tests are actually testing is the TODO comment that I'm
removing: that installing the default copy of bundler doesn't affect any
already installed copies of bundler as regular gems.
https://github.com/rubygems/rubygems/commit/7ca8831d72
Currently `gem uninstall --all` shows the following incorrect message
after completion:
```
INFO: Uninstalled all gems in
```
Now it shows something that actually makes sense like:
```
INFO: Uninstalled all gems in /home/deivid/Code/rubygems/tmp/test_rubygems_6986/gemhome
```
https://github.com/rubygems/rubygems/commit/8fa05e8f8c
These tests work on jruby, but the flags to the system command used to
detect whether `cmake` is present seem to be ignored on jruby and the
output is printed to screen instead of being sent to /dev/null. This
results in very verbose tests, like this:
```
$ rake TESTOPTS=--name=TestGemExtCmakeBuilder#test_self_build
(... warnings skipped ...)
Skipping `gem cert` tests on jruby.
Skipping Gem::Security tests on jruby.
Run options: --name=TestGemExtCmakeBuilder#test_self_build --seed 16839
# Running:
/home/deivid/Code/rubygems/test/rubygems/test_gem_ext_cmake_builder.rb:13: warning: system does not support options in JRuby yet: {:out=>"/dev/null", :err=>[:child, :out]}
Usage
cmake [options] <path-to-source>
cmake [options] <path-to-existing-build>
Specify a source directory to (re-)generate a build system for it in the
current working directory. Specify an existing build directory to
re-generate its build system.
Run 'cmake --help' for more information.
.
Finished in 0.387301s, 2.5820 runs/s, 20.6558 assertions/s.
1 runs, 8 assertions, 0 failures, 0 errors, 0 skips
Coverage report generated for Unit Tests to /home/deivid/Code/rubygems/coverage. 2258 / 8832 LOC (25.57%) covered.
```
By using `Open3`, we get the test output clean:
```
$ rake TESTOPTS=--name=TestGemExtCmakeBuilder#test_self_build
(... warnings skipped ...)
Skipping `gem cert` tests on jruby.
Skipping Gem::Security tests on jruby.
Run options: --name=TestGemExtCmakeBuilder#test_self_build --seed 22605
# Running:
.
Finished in 0.381959s, 2.6181 runs/s, 20.9446 assertions/s.
1 runs, 8 assertions, 0 failures, 0 errors, 0 skips
Coverage report generated for Unit Tests to /home/deivid/Code/rubygems/coverage. 2258 / 8832 LOC (25.57%) covered.
```
https://github.com/rubygems/rubygems/commit/531ce37ea3
I don't know why it was living at the class level. At first I thought it
would be to reuse some server instances between tests, but they seem to
be cleaned up after every test anyways, so I don't think any of it is
needed.
https://github.com/rubygems/rubygems/commit/04bee71216
- Resolver asked Molinillo to resolve-then-activate, which led to using Gem::NameTuple before any require had been passed
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
https://github.com/rubygems/rubygems/commit/e11782b0c8
Some tests had failed under `umask 077` mode. As far as I investigated,
there is no actual bug. All failures were caused by tests that create a
wrong-permission file or expect wrong permission.
This changeset fixes the tests.
https://github.com/rubygems/rubygems/commit/078213e527
* Support XDG_CONFIG_HOME for gemrc.
* Support XDG_DATA_HOME for .gem
* Added test for XDG_DATA_HOME
* Do not reuse environmental variable.
* Unify .rdoc path to RDoc.home.
* Support XDG_DATA_HOME for .rdoc
* Ignore exists?
* Extracted config_home path
* Use XDG_CONFIG_HOME for default credential path
* Fixed inconsistency location.
* Fixed the broken tests.
* Support XDG_CONFIG_HOME for irbrc
* Introduce Gem.cache_home as XDG_CACHE_HOME
* Use Gem.cache_home instead of Gem.config_home for the credential file of RubyGems.
* Initialized the old configurations
* Fixed test failure related the configuration initialization
* restore XDG_DATA_HOME
* Fixed the broken examples of bundler with XDG_*
* Do not modify environmental variable on test file
* Use XDG_DATA_HOME insted of XDG_CACHE_HOME for credential file
* stub out Gem.data_home
* Move dir accessor to defaults.rb file
* Use XDG_DATA_HOME for signed gem features
* Use XDG_DATA_HOME for spec cache
* Do not rely on Gem.user_home
* Gem.user_home is always exists. Don't need to use FileUitls.mkdir_p
* Bump support version to RubyGems 3.2.0+
* Removed the needless fallback configuration
* Fixed the inconsistency methods that are find_config_file and config_file
* Use Gem.configuration.credentials_path instead of hard-coded path
* gem_path is always provided
* Removed the duplicated code of find_home
* Also removed the duplicated code of user_home
* use Gem::UNTAINT instead of untaint for surpressing the warnings
* Use File.directory
* Restore XDG_DATA_HOME
* Use File.write
https://rubyci.org/logs/rubyci.s3.amazonaws.com/ubuntu1604/ruby-master/log/20200203T003005Z.log.html.gz
```
/home/hsbt/chkbuild/tmp/build/20200203T003005Z/ruby/test/rubygems/test_gem_remote_fetcher.rb:485: warning: method redefined; discarding old test_fetch_path_socket_error
/home/hsbt/chkbuild/tmp/build/20200203T003005Z/ruby/test/rubygems/test_gem_remote_fetcher.rb:167: warning: previous definition of test_fetch_path_socket_error was here
```
* Fix gem pristine not accounting for user installed gems. Pull request
#2914 by Luis Sagastume.
* Refactor keyword argument test for Ruby 2.7. Pull request #2947 by
SHIBATA Hiroshi.
* Fix errors at frozen Gem::Version. Pull request #2949 by Nobuyoshi
Nakada.
* Remove taint usage on Ruby 2.7+. Pull request #2951 by Jeremy Evans.
* Check Manifest.txt is up to date. Pull request #2953 by David Rodríguez.
* Clarify symlink conditionals in tests. Pull request #2962 by David
Rodríguez.
* Update command line parsing to work under ps. Pull request #2966 by
David Rodríguez.
* Properly test `Gem::Specifications.stub_for`. Pull request #2970 by
David Rodríguez.
* Fix Gem::LOADED_SPECS_MUTEX handling for recursive locking. Pull request
#2985 by MSP-Greg.
Some test cases in rubygems assume that /tmp/Gemfile does not exist.
If it does, they fail with very difficult-to-understand message:
```
[ 149/2108] TestGemBundlerVersionFinder#test_bundler_version_with_bundle_update_bundler = 0.00
1) Failure:
TestGemBundlerVersionFinder#test_bundler_version_with_bundle_update_bundler [/home/mame/work/ruby/test/rubygems/test_gem_bundler_version_finder.rb:38]:
Expected Gem::Version.new("2.0.2") to be nil.
```
I spent one hour to debug this issue. To prevent the same accident,
this change makes the test suite stop when /tmp/Gemfile explicitly.
Fixes#2290.
1. `Gem::Specification.date` returns SOURCE_DATE_EPOCH when defined,
2. this commit makes RubyGems set it _persistently_ when not provided.
This combination means that you can build a gem, check the build time,
and use that value to generate a new build -- and then verify they're
the same.
https://github.com/rubygems/rubygems/commit/d830d53f59
https://github.com/rubygems/rubygems/pull/1868 changes the behavior
of require when it used with -I options. Therefore, the options of
ruby repository was different from rubygems/rubygems.
Sometimes it happens to me that my local tests start failing because I
pull some file removals or renames into my local copy, and those are
still present on my last copy of pkg/. In those cases, the test about
`rake package` will fail with something like the following:
````
Failure:
TestRakePackage#test_builds_ok [/home/deivid/Code/rubygems/test/rubygems/test_rake_package.rb:13]:
Expected `rake package` to work, but got errors:
```
cd pkg/rubygems-update-3.1.0.pre1
WARNING: See http://guides.rubygems.org/specification-reference/ for help
rake aborted!
Gem::InvalidSpecificationException: ["test/rubygems/test_rake_package.rb"] are not files
Tasks: TOP => package => gem => pkg/rubygems-update-3.1.0.pre1.gem
(See full trace by running task with --trace)
```
If you have added or removed files, make sure you run `rake update_manifest` to update the `Manifest.txt` accordingly.
Expected: true
Actual: false
````
So, make sure, package is always built from scratch.
https://github.com/rubygems/rubygems/commit/4e2cc9eb26
This was never the right place. The method got there just by evolution,
not by design. Move it within default methods, where it suits better.
Since this method is presumably used just internally, it should be safe
to deprecate it and remove later.
https://github.com/rubygems/rubygems/commit/0c0dd9458a
Separate #add_runtime_dependency and #add_development_dependency
availability condition from #specification_version availability,
which is not related to directly.
Also check if the former method is available, instead of comparing
the version.
https://github.com/rubygems/rubygems/commit/5cccc2b836
When `GEM_HOME` was shared with CRuby and JRuby. RubyGems try to
handle both platforms. It should be ignored the different platform.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67190 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This version contains the some style changes by RuboCop.
* 9d810be0ed
* 61ea98a727
* 795893dce3
* 9be7858f7f
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67074 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This reverts commit d12bcfc186.
pause on --jit-wait looks not working... I'll fix that first.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65910 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* It enabled `USE_BUNDLER_FOR_GEMDEPS` for using gemdeps of rubygems.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65517 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
r65308 passed both trunk-mjit and trunk-mjit-wait CIs. MJIT copy job
looks working fine. Then this commit skips 5 more tests. Some of them
were skipped in a very early stage and may still need to be skipped, but
I want to confirm them since they haven't been changed for a long time.
And this prefers having inline information on `RubyVM::MJIT.enabled?`.
This commit makes it easier to confirm whether there's suspicious test
skip by RubyVM::MJIT.enabled? or not.
After this commit, tentatively we're not skipping tests for MJIT other
than `assert_no_memory_leak` ones.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65311 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
David Rodríguez
Takashi Kokubun
Yusuke Endoh
Hiroshi SHIBATA
Vít Ondruch
bronzdoc
Nobuyoshi Nakada
Brandon Fish
Josef Šimánek
Dmytro Shyrshov
Benoit Daloze
Olle Jonsson
Jeremy Evans
Kazuhiro NISHIYAMA
f
Ellen Marie Dash
Daniel Berger
Alexander Pakulov
Samuel Giddins
Daniel Berger
hsbt
k0kubun
nobu
naruse