Age | Commit message (Collapse) | Author |
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3270
|
|
|
|
|
|
|
|
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]
Notes:
Merged: https://github.com/ruby/ruby/pull/3174
|
|
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]
Notes:
Merged: https://github.com/ruby/ruby/pull/3157
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/4f519638ae
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/a6d50afad0
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/ef2dae4222
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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>
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/ef2dae4222
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
This is not a remembered option, so it shouldn't have been deprecated.
At least not for that reason.
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/84e4c58e83
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/e3f60d8aec
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/a73fa0760e
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/f52733f6a4
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/4d1a0c465a
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/746a4b3d74
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
errors
https://github.com/rubygems/rubygems/commit/6bac832a58
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
creation
https://github.com/rubygems/rubygems/commit/9e5f7a9099
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/2af2abe5fd
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/288f073c3c
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
consistent
* Add hints for --ci option
https://github.com/rubygems/rubygems/commit/5f779f45b0
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/39b18fe7fc
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
Co-authored-by: Olle Jonsson <olle.jonsson@gmail.com>
https://github.com/rubygems/rubygems/commit/24f3739585
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/80571452ca
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/d8e416d89b
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
* `bundle gem` has new option to select CI provider
https://github.com/rubygems/rubygems/commit/320f3546c1
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
* `bundle gem` has new option to choose CI provider other than Travis CI
https://github.com/rubygems/rubygems/commit/afaecf16de
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/22cb599bcc
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/80260b3496e357bf96ffe6f381e29bf25b6749cb
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
These specs doesn't really need an installed bundle, they only need a
`Gemfile`.
https://github.com/rubygems/rubygems/commit/06c85683ae
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
https://github.com/rubygems/rubygems/commit/ade0c441d5
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
They don't need to run that many commands, and the new version is also
more readable in my opinion.
https://github.com/rubygems/rubygems/commit/efff3e3210
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
They are preceded by `install_gemfile` calls, which mean `bundle
install` is being run twice for no reason.
https://github.com/rubygems/rubygems/commit/d2b2d10862
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
This command was silently failing but doesn't really affect the outcome
of the spec.
https://github.com/rubygems/rubygems/commit/7880d08146
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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:
* https://github.com/rubygems/bundler/commit/105654a31e07e9b0a198f1a5a5ec94e365854edf
* https://github.com/rubygems/bundler/commit/ae53be1f8748bfc41bc6565dc4922a1c0ac80998
* https://github.com/rubygems/bundler/commit/d19f4a7b32ccf4ec4ecda5c7c0354adc81e1efb6
* https://github.com/rubygems/bundler/commit/092f169d01472336598e29b32550399991940d63
* https://github.com/rubygems/bundler/commit/36878435b5f0be75fc6f2e07cebd7f15aaddadf0
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
The inner specs have separated specs for the `< 3` and `= 2` cases, so
this outer tag is incorrect.
https://github.com/rubygems/rubygems/commit/61e905ca27
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3212
|