* Enables Mutex to be used as synchronization between multiple Fibers
of the same Thread.
* With a Fiber scheduler we can yield to another Fiber on contended
Mutex#lock instead of blocking the entire thread.
* This also makes the behavior of Mutex consistent across CRuby, JRuby and TruffleRuby.
* [Feature #16792]
`llvm-strip-7` is a sane valid strip command that LLVM 7 ships, albeit
it does not understand `--version`. It is a bad idea to check that
option. Instead just see if the command actually strips something. A
copy of `/bin/sh` should suffice. That file must be ubiquitous.
* Fix debug documents to match Thread#to_s change (Feature #16412 ticket)
* TracePoint#inspect returns "... file:line" (Feature #16513)
* Guard older version of Ruby in Tracepoint inspection tests
* Focus on current thread only when running TracePoint inspection test
The newly added specs needs to be tagged as
:readline, otherwise they fail on Windows with
the backtrace: `ZeroDivisionError: divided by 0`.
Such issues are already being skipped on Windows.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/391f860af4
Since this PR was made because we missed checking
RuboCop offenses with different flags, therefore
adding tests so that all flag combinations are
tested.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/d08250efc2
The Gemfile wasn't properly put in the last commit.
As a result, Layout/EmptyLines inspected an offense
in the Gemfile.
This also fixes the spec w.r.t change in the task
default.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/d1418fddd3
It simplifies things and should avoid issues like the one we had where
the master branch had a bad `.gitattributes` file and changing it on a
PR would be disregarded.
In order for this to work, we need to make sure to fetch all tags from
the repository, so that they can properly be checked out later. This
does not apply to the case of testing against `RGV=..`, since no extra
cloning is needed there.
https://github.com/rubygems/rubygems/commit/d088d936b8
ruby_core has an 'ast.rb' file that gets in the
middle and breaks this spec, so it's better we skip
this test on this workflow for now.
Also, slightly change the spec name from "run" to
"runs" and change the last assertion, it's cleaner
to check empty error.
Thanks to David Rodríguez for this!
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/ba8eaa70c3
With older versions of rubocop, the dependency on
`jaro_winkler` seems to be a pain.
However, in the later versions of rubocop, this
dependency was dropped. So we only need to use
the older version for ruby2.3.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/9cd87eaee3
because rubocop configuration inheritance is
messed up and when using `--ignore-parent-exclusion`,
even though the exit status is 0, the example
still fails because of the configuration issue.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/3e20b2738c
The later RuboCop versions don't work with ruby2.3
so we should lock the version to what works with
ruby2.3 as we haven't dropped the support yet.
And since we're using the older version of rubocop,
also fix `Max` value of `LineLength` to 120, which
is the current standard. Without this, rubocop
will throw the line length offenses.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/46d0a800a2
Previously, we were using the old syntax like:
`task :default => :spec`, but now this commit
uses the new Ruby 1.9 hash syntax.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/b41d0fdb56
Using File.open without a block leaves a file reference that causes issues with file operations
commands/binstubs_spec.rb
install/gems/compact_index_spec.rb
install/gems/dependency_api_spec.rb
install/gems/standalone_spec.rb
runtime/executable_spec.rb
https://github.com/rubygems/rubygems/commit/4b9a6ca156
Previously, these were not implemented, and Object#== and #eql?
were used. This tries to check the proc internals to make sure
that procs created from separate blocks are treated as not equal,
but procs created from the same block are treated as equal, even
when the lazy proc allocation optimization is used.
Implements [Feature #14267]
This makes:
```ruby
args = [1, 2, -> {}]; foo(*args, &args.pop)
```
call `foo` with 1, 2, and the lambda, in addition to passing the
lambda as a block. This is different from the previous behavior,
which passed the lambda as a block but not as a regular argument,
which goes against the expected left-to-right evaluation order.
This is how Ruby already compiled arguments if using leading
arguments, trailing arguments, or keywords in the same call.
This works by disabling the optimization that skipped duplicating
the array during the splat (splatarray instruction argument
switches from false to true). In the above example, the splat
call duplicates the array. I've tested and cases where a
local variable or symbol are used do not duplicate the array,
so I don't expect this to decrease the performance of most Ruby
programs. However, programs such as:
```ruby
foo(*args, &bar)
```
could see a decrease in performance, if `bar` is a method call
and not a local variable.
This is not a perfect solution, there are ways to get around
this:
```ruby
args = Struct.new(:a).new([:x, :y])
def args.to_a; a; end
def args.to_proc; a.pop; ->{}; end
foo(*args, &args)
# calls foo with 1 argument (:x)
# not 2 arguments (:x and :y)
```
A perfect solution would require completely disabling the
optimization.
Fixes [Bug #16504]
Fixes [Bug #16500]
Passing paths should work in most cases, but on Windows the driver
letter is interpreted as the scheme and causes some case mismatches
because
```
irb> URI.parse("E:").to_s
=> "e:"
```
We fix this by passing file URI's instead.
https://github.com/rubygems/rubygems/commit/b6bc517628
Currently, there is no `.rubocop.yml` shipped by default.
So when a user runs `rubocop` after creating a new gem via
`bundle gem foo`, it throws a bunch of offenses.
With the default `.rubocop.yml` present, the number of those
offenses significantly reduce by 25.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
We have a check on an `at_exit` hook that checks that system bundler is
never loaded instead of our development copy. The check was failing in
these cases, but in a silent way because the errors were being swallowed.
This commit changes these specs to make sure they load the right
bundler.
https://github.com/rubygems/rubygems/commit/cd1c1bc297
On bundler 3, the `--deployment` flag doesn't exist, so the `bundle
install --deployment` command was failing silently and the spec was
verifying a different scenario.
Change the spec to work the same regardless of bundler's major version.
Also, from the spec description it was not apparently that a specific
case involving deployment mode was being tested, so I reworded it to
make it more apparent.
https://github.com/rubygems/rubygems/commit/3e33e2b927
On bundler 3, where the default install path is `.bundle`, these specs
were trying to change permissions of the
`.bundle/ruby/<ruby_abi_version>` folder, which didn't exist yet,so the
permission changing command was failing and the spec was not testing the
right thing.
Change the specs so that the permissions are correctly changed, by first
configuring the local path to be `.bundle` (which creates the `.bundle`
folder), and then changing permissions of the `.bundle` folder
explicitly, which exists already.
https://github.com/rubygems/rubygems/commit/2833162fb0
Bundler 3 installs by default to `.bundle`. That means that, because the
`bar` gem was not previously available at this location but as a system
gem, the initial `bundle install` was silently failing. As a
consequence, the spec was not testing the exact scenario it meant to
test.
https://github.com/rubygems/rubygems/commit/202399521c
This spec is specifically testing for the case where there's no
`Gemfile.lock` file and it's only doing the expected thing because the
`bundle install` command is silently failing. Remove the `bundle
install` to reduce confusion.
https://github.com/rubygems/rubygems/commit/ec39fbde0e
This command is failing because of the same reason that the subsequent
`bundle exec` is failing: the gemspec is invalid. The `bundle install`
here deviates the `bundle exec` focus from the test and is unnecessary:
all we need is a `Gemfile` that will trigger the `bundle exec`, so let's
create and avoid the extra command.
https://github.com/rubygems/rubygems/commit/eb83cf6cf1
It turns out that this test is checking essentially nothing useful. The
paperclip gem doesn't exist in our setup, so initial install is failing
and the test is only checking that calling `bundle check` 3 times on a
broken setup always returns the same thing.
I went to the history of this test:
* 105654a31e
* ae53be1f87
* d19f4a7b32
* 092f169d01
* 36878435b5
And have finally decided to remove it since I'm not sure changing it to
something else will lead to testing something useful and not already
tested.
https://github.com/rubygems/rubygems/commit/6184322967
This spec was broken. The second `bundle install` was silently failing.
This means that the spec was actually checking an scenario completely
different from the one that was supposed to be tested. And also a very
dummy one: that running `bundle cache` twice doesn't cache a completely
unrelated gem.
https://github.com/rubygems/rubygems/commit/f11a5d2df9
The commands these specs run were throwing warnings in bundler 2, and
failing on bundler 3, effectively testing a different scenario to what
they were supposed to.
https://github.com/rubygems/rubygems/commit/97ac1ced49
The `rails_fail` name is misleading because there's no specific reason
why such a gem would need to fail. As a matter of fact, `bundle
install`'ing a Genfile with only that dependency like the spec the
previous commit adds is not expected to fail.
https://github.com/rubygems/rubygems/commit/b947f40701
The `only_update_to_newer_versions` feature flag will enable some new
behaviour in bundler 3 (or maybe earlier if we decide to consider it a
bug fix) that prevents `bundle update` from unexpectedly downgrading
direct dependencies.
This seems reasonable, but the current implementation is adding
additional requirements for all locked dependencies, not only from the
ones in the `Gemfile`. That causes some situations where the `Gemfile`
is edited and will resolve to older versions to start failing.
This commit fixes the problem by making sure extra requirements are
added exclusively for direct dependencies in the `Gemfile`, not for all
direct dependencies in the lock file.
https://github.com/rubygems/rubygems/commit/128b4596e1
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.
I had to pin `redis-namespace` in our spec to 1.6.0 because on ruby
2.3.0 the spec no longer resolved to that version, so the cached `.gem`
file was missing there.
Previously it was failing and not recording. Also, the
`BUNDLER_SPEC_FORCE_RECORD` environment variable was forcing every
request to be recorded, including duplicated requests to the same
endpoint. That meant the recorded `versions` file would be incorrect
because it would contain the result of the last request, which would be
`304 NOT MODIFIED`.
So, to rerecord, delete cassettes and let them be recorded when needed.
* bundle gem previously ignored gem.test when passed empty -t flag,
defaulting to RSpec
* bundle gem will now ask user for test framework when passed empty -t
flag and gem.test is set to false, but will not overwrite gem.test
* thor option parsing for String types falls back to human name for nil,
so setting lazy_default to nil won't work
* c5161501e0/lib/thor/parser/options.rb (L224)
Default to Bundler.settings["gem.test"] for empty --test
Add shared examples for test framework to newgem spec
Add examples for empty --test flag to newgem spec
Simplify conditional for prompting test framework
Follow naming conventions for bundler settings
Add more descriptive test framework help text for bundle gem
Update man pages for bundler
https://github.com/rubygems/rubygems/commit/ab0785a09f
Instead, use the non-deprecated option except when specifically testing
deprecated CLI flags. In that case, pass the flag directly and limit
the specs to `bundler < 3`.
https://github.com/rubygems/rubygems/commit/3d5e186241
Some of them were passing "by chance" because they used a `bundle
install` command that failed, but the assertion was using the result of
the previous. Others were skipped on bundler 3. Now they all pass in all
versions.
https://github.com/rubygems/rubygems/commit/cedf611e11
This spec was originally written many years ago to verity gems were
properly "remembered" in the lock file. At this point, the test feels a
bit dummy since the first `bundle install` already runs on a "clean
machine".
https://github.com/rubygems/rubygems/commit/dbfefb3f5a
When bundler specs are run from a ruby tarball (ruby-core does this),
there's no git folder, so `git ls-files` fails.
Support this case by making specs rely on the list of files from the
bundler gemspec instead, and invert the spec that makes sure we ship the
right set of files.
As per the other quality specs, skip them in this case.
https://github.com/rubygems/rubygems/commit/b28d5ec931
And never recommend it inside CLI messages.
This flag represents the default behaviour of `bundle install`, and the
only reason it exists is to "override" previous `--deployment` flag
usages which were silently remembered. So it should be deprecated just
like all the other flags the rely on remembering their values across
invocations.
https://github.com/rubygems/rubygems/commit/40e50b7190
This fixes various issues when a module is included in or prepended
to a module or class, and then refined, or refined and then included
or prepended to a module or class.
Implement by renaming ensure_origin to rb_ensure_origin, making it
non-static, and calling it when refining a module.
Fix Module#initialize_copy to handle origins correctly. Previously,
Module#initialize_copy did not handle origins correctly. For example,
this code:
```ruby
module B; end
class A
def b; 2 end
prepend B
end
a = A.dup.new
class A
def b; 1 end
end
p a.b
```
Printed 1 instead of 2. This is because the super chain for
a.singleton_class was:
```
a.singleton_class
A.dup
B(iclass)
B(iclass origin)
A(origin) # not A.dup(origin)
```
The B iclasses would not be modified, so the includer entry would be
still be set to A and not A.dup.
This modifies things so that if the class/module has an origin,
all iclasses between the class/module and the origin are duplicated
and have the correct includer entry set, and the correct origin
is created.
This requires other changes to make sure all tests still pass:
* rb_undef_methods_from doesn't automatically handle classes with
origins, so pass it the origin for Comparable when undefing
methods in Complex. This fixed a failure in the Complex tests.
* When adding a method, the method cache was not cleared
correctly if klass has an origin. Clear the method cache for
the klass before switching to the origin of klass. This fixed
failures in the autoload tests related to overridding require,
without breaking the optimization tests. Also clear the method
cache for both the module and origin when removing a method.
* Module#include? is fixed to skip origin iclasses.
* Refinements are fixed to use the origin class of the module that
has an origin.
* RCLASS_REFINED_BY_ANY is removed as it was only used in a single
place and is no longer needed.
* Marshal#dump is fixed to skip iclass origins.
* rb_method_entry_make is fixed to handled overridden optimized
methods for modules that have origins.
Fixes [Bug #16852]
WSL 2 is officially released. It uses Linux kernel, so almost all specs
for Linux work on WSL, except one: gethostbyaddr. I guess network
resolution in WSL is based on Windows, so the behavior seems a bit
different from normal Linux.
This change adds `platform_is_not :wsl` guard, and guards out the test
in question.
```
1) bundle version with version outputs the version with build metadata
Failure/Error: expect(out).to match(/\ABundler version #{Regexp.escape(Bundler::VERSION)} \(\d{4}-\d{2}-\d{2} commit #{COMMIT_HASH}\)\z/)
expected "Bundler version 2.2.0.dev (2020-05-25 commit )" to match /\ABundler version 2\.2\.0\.dev \(\d{4}-\d{2}-\d{2} commit (?-mix:unknown|[a-fA-F0-9]{7,})\)\z/
Diff:
@@ -1,2 +1,2 @@
-/\ABundler version 2\.2\.0\.dev \(\d{4}-\d{2}-\d{2} commit (?-mix:unknown|[a-fA-F0-9]{7,})\)\z/
+"Bundler version 2.2.0.dev (2020-05-25 commit )"
Commands:
$ /home/user/snapshot-master/ruby -I/home/user/snapshot-master/spec/bundler -r/home/user/snapshot-master/spec/bundler/support/artifice/fail.rb -r/home/user/snapshot-master/spec/bundler/support/hax.rb /home/user/snapshot-master/tmp/1/gems/system/bin/bundle version
Bundler version 2.2.0.dev (2020-05-25 commit )
# $? => 0
```
https://github.com/ruby/actions/runs/703745101?check_suite_focus=true#step:16:27
```
An error occurred in a `before(:suite)` hook.
Failure/Error: contents = File.read(version_file)
Errno::ENOENT:
No such file or directory @ rb_sysopen - /home/runner/work/actions/actions/snapshot-master/tmp/1/bundler-2.2.0.dev/lib/bundler/version.rb
```
Android is Linux, but the clock resolution is 10 milliseconds.
I think that 1 microsecond is too strict for embedded environment.
This change laxes the limit to 10 milliseconds.
* 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
This changes the following warnings:
* warning: class variable access from toplevel
* warning: class variable @foo of D is overtaken by C
into RuntimeErrors. Handle defined?(@@foo) at toplevel
by returning nil instead of raising an exception (the previous
behavior warned before returning nil when defined? was used).
Refactor the specs to avoid the warnings even in older versions.
The specs were checking for the warnings, but the purpose of
the related specs as evidenced from their description is to
test for behavior, not for warnings.
Fixes [Bug #14541]
On platform where searchs shared libraries by `PATH` environment
variable (i.e., Windows), the shared library is installed in
`bindir`. On other platforms, the library directory is directed
by `libdirname` indirectly.
`time_with_zone.zone.should == (time_with_zone - 60*60).zone` fails when
the time is immediately before the change of summer time.
https://rubyci.org/logs/rubyci.s3.amazonaws.com/unstable11s/ruby-master/log/20200328T232504Z.fail.html.gz
```
1)
Time#+ preserves time zone FAILED
Expected "CET" == "CEST"
to be truthy but was false
```
It is acceptable as it fails at most twice per year, but it would be
good to use near time objects to reduce the possibility.
https://github.com/ruby/ruby/runs/541455267
```
1)
RbConfig::CONFIG libdir/LIBRUBY_SO is the path to libruby and it exists if and only if ENABLE_SHARED FAILED
Expected File.exist? "d:/Ruby26-x64/lib/x64-msvcrt-ruby260.dll"
to be truthy but was false
D:/a/ruby/ruby/src/spec/ruby/library/rbconfig/rbconfig_spec.rb:46:in `block (3 levels) in <top (required)>'
D:/a/ruby/ruby/src/spec/ruby/library/rbconfig/rbconfig_spec.rb:4:in `<top (required)>'
```
This freezes the clone even if the receiver is not frozen. It
is only for consistency with freeze: false not freezing the clone
even if the receiver is frozen.
Because Object#clone is now partially implemented in Ruby and
not fully implemented in C, freeze: nil must be supported to
provide the default behavior of only freezing the clone if the
receiver is frozen.
This requires modifying delegate and set, to set freeze: nil
instead of freeze: true as the keyword parameter for
initialize_clone. Those are the two libraries in stdlib that
override initialize_clone.
Implements [Feature #16175]
As a semantics, Hash#each yields a 2-element array (pairs of keys and
values). So, `{ a: 1 }.each(&->(k, v) { })` should raise an exception
due to lambda's arity check.
However, the optimization that avoids Array allocation by using
rb_yield_values for blocks whose arity is more than 1 (introduced at
b9d2960337 and some commits), seemed to
overlook the lambda case, and wrongly allowed the code above to work.
This change experimentally attempts to make it strict; now the code
above raises an ArgumentError. This is an incompatible change; if the
compatibility issue is bigger than our expectation, it may be reverted
(until Ruby 3.0 release).
[Bug #12706]
Previously, if an object has a singleton class, and you call
Object#method on the object, the resulting string would include
the object's singleton class, even though the method was not
defined in the singleton class.
Change this so the we only show the singleton class if the method
is defined in the singleton class.
Fixes [Bug #15608]
When providing a single array to a block that takes a splat, pass the
array as one argument of the splat instead of as the splat itself,
even if the block also accepts keyword arguments. Previously, this
behavior was only used for blocks that did not accept keywords.
Implements [Feature#16166]
FreeBSD's GETNAMEINFO(3) says:
> If a link-layer address or UNIX-domain address is passed to
> getnameinfo(), its ASCII representation will be stored in host. The
> string pointed to by serv will be set to the empty string if non-NULL;
> flags will always be ignored.
Android seems to behave like FreeBSD.
Benoit Daloze
Marc-Andre Lafortune
Hiroshi SHIBATA
Nobuyoshi Nakada
卜部昌平
Nguyễn Quang Minh
David Rodríguez
Kazuhiro NISHIYAMA
Jeremy Evans
Utkarsh Gupta
MSP-Greg
Koichi Sasada
Bart de Water
Frank Lam
Yuki Nishijima
Carsten Wirth
DEVRAJ KUMAR
Jean Boussier
Yusuke Endoh
Samuel Williams
Takashi Kokubun
dependabot[bot]