| Age | Commit message (Collapse) | Author |
|---|
|
- The command can either be run using:
1. `bundle doctor --ssl`
2. `bundle doctor ssl`
The later is most useful when you need to specify
custom ssl options (such as the verify mode or the
TLS version when running the diagnostic).
The implementation will follow in the next commits.
https://github.com/rubygems/rubygems/commit/993d12874c
|
|
- See explanation in previous commit https://github.com/rubygems/rubygems/commit/170890befb4c
https://github.com/rubygems/rubygems/commit/8f1b5a4479
|
|
0363..036F ; Alphabetic # Mn [13] COMBINING LATIN SMALL LETTER A..COMBINING LATIN SMALL LETTER X
Notes:
Merged: https://github.com/ruby/ruby/pull/13117
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13117
|
|
platforms
https://github.com/rubygems/rubygems/commit/c39d2f84fd
|
|
incompatible
https://github.com/rubygems/rubygems/commit/282e4a8593
|
|
In frozen mode, the previous logic would not set the platform locked
originally in the materialized specification, and that would trigger the
warning about insecure materialization incorrectly.
https://github.com/rubygems/rubygems/commit/a18001e10c
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/11975
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/11975
|
|
Don't mention "Found changes from the lockfile" because that's not
really true in general.
https://github.com/rubygems/rubygems/commit/0181c278e8
|
|
If both a native and a generic version are locked, but the native
version is incompatible with the running Ruby, Bundler will still keep
the native version in the lockfile, since it could be potentially useful
when using other rubies.
However, when `bundle update` is run, this was not the case because the
locked native gems were not using the right source when materializing.
They were using the lockfile source instead of the Gemfile source, and
that meant they could not be found when materializing, because the
lockfile source always uses local mode so does not see them.
The effect of this was normally that they were incorrectly removed from
the lockfile and a strange "this spec has been possibly yanked" was
printed in verbose mode. However, in certain situations (i.e., when the
generic gem would bring extra dependencies), it could also make `bundle
update` crash.
The solution is, when adding this extra locked specs to the result after
resolving, maybe sure they inherit the source from the resolved specs,
so they can be found when materializing.
`bundle install` did not have the issue because it passes locked specs
to the resolver, and assigns the right source to them in
`Definition#converge_locked_specs`.
https://github.com/rubygems/rubygems/commit/91ce881fda
|
|
https://github.com/rubygems/rubygems/commit/458fa5dc4c
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13083
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12759
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12847
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12847
|
|
Originally, if a class was defined with the class keyword, the cref had a
const_added callback, and the superclass an inherited callback, const_added was
called first, and inherited second.
This was discussed in
https://bugs.ruby-lang.org/issues/21143
and an attempt at changing this order was made.
While both constant assignment and inheritance have happened before these
callbacks are invoked, it was deemed nice to have the same order as in
C = Class.new
This was mostly for alignment: In that last use case things happen at different
times and therefore the order of execution is kind of obvious, whereas when the
class keyword is involved, the order is opaque to the user and it is up to the
interpreter.
However, soon in
https://bugs.ruby-lang.org/issues/21193
Matz decided to play safe and keep the existing order.
This reverts commits:
de097fbe5f3df105bd2a26e72db06b0f5139bc1a
de48e47ddf78aba02fd9623bc7ce685540a10743
Notes:
Merged: https://github.com/ruby/ruby/pull/13085
|
|
https://github.com/rubygems/rubygems/commit/5b312fd040
|
|
https://github.com/rubygems/rubygems/commit/08b3c48f41
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13037
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13037
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13037
|
|
Instead, skip the spec when run by ruby-core. Maybe the root cause can
be fixed at some point.
https://github.com/rubygems/rubygems/commit/09594ae5b8
|
|
mutable dependencies array
That restores support for compact index dummy implementations that only lists
versions, without checksums or dependencies.
This format is undocumented, so we may want to get rid of it in the
future. However, some of our tests rely on it, and some implementations
did use it (gems.mutant.dev at least). And the way the code was written
suggest that support was intentional.
So for now, we should restore it.
https://github.com/rubygems/rubygems/commit/0427d8c983
|
|
have changed
Since we will now add it back if the final resolution is compatible, we
can also get this kind of edge case (`bundle add`) working.
https://github.com/rubygems/rubygems/commit/cdc5ebec77
|
|
Instead, remove them anytime we find dependencies don't match the
lockfile for a platform, and then add them back after resolution if
they ended up being valid.
https://github.com/rubygems/rubygems/commit/220bd77887
|
|
spec/ruby/security/cve_2020_10663_spec.rb
Notes:
Merged: https://github.com/ruby/ruby/pull/13004
|
|
The following method call:
```ruby
a(*nil)
```
A method call such as `a(*nil)` previously allocated an array, because
it calls `nil.to_a`, but I have determined this array allocation is
unnecessary. The instructions in this case are:
```
0000 putself ( 1)[Li]
0001 putnil
0002 splatarray false
0004 opt_send_without_block <calldata!mid:a, argc:1, ARGS_SPLAT|FCALL>
0006 leave
```
The method call uses `ARGS_SPLAT` without `ARGS_SPLAT_MUT`, so the
returned array doesn't need to be mutable. I believe all cases where
`splatarray false` are used allow the returned object to be frozen,
since the `false` means to not duplicate the array. The optimization
in this case is to have `splatarray false` push a shared empty frozen
array, instead of calling `nil.to_a` to return a newly allocated array.
There is a slightly backwards incompatibility with this optimization,
in that `nil.to_a` is not called. However, I believe the new behavior
of `*nil` not calling `nil.to_a` is more consistent with how `**nil`
does not call `nil.to_hash`. Also, so much Ruby code would break if
`nil.to_a` returned something different from the empty hash, that it's
difficult to imagine anyone actually doing that in real code, though
we have a few tests/specs for that.
I think it would be bad for consistency if `*nil` called `nil.to_a`
in some cases and not others, so this changes other cases to not
call `nil.to_a`:
For `[*nil]`, this uses `splatarray true`, which now allocates a
new array for a `nil` argument without calling `nil.to_a`.
For `[1, *nil]`, this uses `concattoarray`, which now returns
the first array if the second array is `nil`.
This updates the allocation tests to check that the array allocations
are avoided where possible.
Implements [Feature #21047]
Notes:
Merged: https://github.com/ruby/ruby/pull/12597
|
|
[Feature #21109]
By always freezing when setting the global rb_rs variable, we can ensure
it is not modified and can be accessed from a ractor.
We're also making sure it's an instance of String and does not have any
instance variables.
Of course, if $/ is changed at runtime, it may cause surprising behavior
but doing so is deprecated already anyway.
Co-authored-by: Jean Boussier <[email protected]>
Notes:
Merged: https://github.com/ruby/ruby/pull/12975
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12984
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12984
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12983
|
|
https://github.com/rubygems/rubygems/commit/a0f7851451
|
|
This test confirms that a bug that existed in 2.6.3
was fixed by https://github.com/rubygems/rubygems/commit/b8e55087f026
https://github.com/rubygems/rubygems/commit/9e4ca5c5b2
|
|
This reverts commit eb91c664dc0b4d69db09ae913f2d7a5ef3490d74.
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
missing
https://github.com/rubygems/rubygems/commit/054a0cd76c
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
The deployment setting already does this implicitly.
https://github.com/rubygems/rubygems/commit/402b11fa39
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
with checksums
https://github.com/rubygems/rubygems/commit/8e2c5748d9
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
https://github.com/rubygems/rubygems/commit/7026b5f2e5
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
It reads better this way I think.
https://github.com/rubygems/rubygems/commit/ce9743290d
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
https://github.com/rubygems/rubygems/commit/558a4765c7
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
https://github.com/rubygems/rubygems/commit/e891be9197
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
* Increase timeout to fix flaky tests?
* Fix bundler test - wording changed.
expect "fatal: Remote branch deadbeef not found in upstream origin" to
include "Revision deadbeef does not exist in the repository"
Notes:
Merged-By: ioquatix <[email protected]>
|
|
[Misc #21143]
[Bug #21193]
The previous change caused a backward compatibility issue with code
that called `Object.const_source_location` from the `inherited` callback.
To fix this, the order is now:
- Define the constant
- Invoke `inherited`
- Invoke `const_set`
Notes:
Merged: https://github.com/ruby/ruby/pull/12956
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12622
|
|
Co-authored-by: Nobuyoshi Nakada <[email protected]>
Notes:
Merged: https://github.com/ruby/ruby/pull/12622
|
|
(Bug #21083)
https://bugs.ruby-lang.org/issues/21083
Notes:
Merged: https://github.com/ruby/ruby/pull/12622
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12947
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12798
|
|
|
