Since the change at f310ac1cb2 to show
the backtraces by default, this test started to show the backtraces.
As the backtraces are not the subject of this test, silence them by
using Gem::SilentUI.
This is a regression from a change intended to raise errors when user
puts a gem under an incorrect source in the Gemfile by mistake. To fix
the issue, we revert the change that caused it and implement it in a
different way that restores the resolver independency from real
specifications. Now it deals only with names and versions and does not
try to materialize anything into real specifications before resolving.
https://github.com/rubygems/rubygems/commit/d2bf1b86eb
Do dependency filtering and materialization in one step. Before,
dependency filtering would not consider ruby metadata so it would
discard variants that end up not being materializable in the end.
https://github.com/rubygems/rubygems/commit/0c0d40d417
Co-authored-by: Ian Ker-Seymer <ian.kerseymer@shopify.com>
Fixes case where Object includes a module that defines a constant,
then using class/module keyword to define the same constant on
Object itself.
Implements [Feature #18832]
Previously if `~/.bundle/cache/compact_index/rubygems.org.*/version`
were owned by root with read-only access, `bundle install` would fail
with a misleading error message. For example:
```
There was an error while trying to write to `/tmp/bundler-compact-index-20220711-1823-npllre/versions`. It is
likely that you need to grant write permissions for that path.
```
This happened because the EACCESS error was caught by
`SharedHelpers.filesystem_access`, which makes it look like the target
directory is at fault instead of the source.
We can't simply drop this guard because that causes the opposite
problem: the permission error appears to come from the source instead of
the target, since `CompactIndexClient::Cache#lines` also wraps read
access errors.
Instead, bring a minimal implementation of `FileUtils.cp` and nest calls
to `SharedHelpers.filesystem_access` properly.
https://github.com/rubygems/rubygems/commit/320822c070
Co-authored-by: Stan Hu <stanhu@gmail.com>
When running a command with the `--verbose` flag that ends up raising a
`BundlerError`, Bundler will unnecessarily print the error twice.
This commit fixes the issue by removing the duplicate logging.
https://github.com/rubygems/rubygems/commit/689004a164
When testing under the ruby/ruby setup, mkmf.rb needs to the `$extout`
global variable set properly.
This is because, in this particular case, the `ruby.h` header needed to
compile extensions is constructed from
`$(extout)/include($arch)/ruby/config.h` but `$extout` is not set by
default.
I tried to fix this in mkmf.rb itself but I couldn't figure it. But
setting it externally to workaround the issue fixes the specs, so I'll
start with that. Also setting it externally causes issues when running
specs upstream against Ruby 2.3 (I guess because of some difference with
Ruby 2.3 mkmf.rb implementation). So I'm avoiding doing it on Ruby 2.3 to
woraround that.
https://github.com/rubygems/rubygems/commit/d782984585
The paths for extensions of gems would contain the hardcoded ruby
version on which the extension was built. This will replace it with
runtime ruby version like the parent version directory. It will make the
standalone script compatible between different ruby version installations.
https://github.com/rubygems/rubygems/commit/a9dae93d5d
The `asdf-ruby` plugin sets `RUBYLIB` to require some code to reshim
after installing gems. This interferes with our specs.
Reset that, but leave any "internal" entries in places, because the
ruby-core test setup also uses RUBYLIB.
https://github.com/rubygems/rubygems/commit/4b2d09af5b
These gemspecs already work most of the times. When they are installed
normally, the require_paths in the gemspec stub line becomes actually
correct, and the incorrect value in the real gemspec is ignored. It only
becomes an issue in standalone mode.
In Ruby 3.2, `Kernel#=~` has been removed, and that means that it
becomes harder for us to gracefully deal with this error in standalone
mode, because it now happens earlier due to calling `Array#=~` for this
invalid gemspec (since require_paths is incorrectly an array of arrays).
The easiest way to fix this is to actually make this just work instead
by automatically fixing the issue when reading the packaged gemspec.
https://github.com/rubygems/rubygems/commit/d3f2fe6d26
Prior to this commit, `bundle add GEM_NAME` updated the lockfile,
but `bundle remove GEM_NAME` left GEM_NAME in the lockfile.
By invalidating the cached `Bundle.definition`, the existing code
handles that without a problem.
https://github.com/rubygems/rubygems/commit/aa0794d6a9
The installer is actually rewriting the spec's full gem path to be the
one of the newly installed gem, however the accessor was not properly
working for `StubSpecification` instances, and default gems are always
of this type, because they are always present locally.
Fix the accessor to properly update the underlying full specification.
https://github.com/rubygems/rubygems/commit/efa41babfa
Generally this warning is skipped for gemspec development dependencies.
I think because it's common to override them in the Gemfile to change
the source, for example.
But the order of conditions was not correct and the warning was still
being printed in one case.
https://github.com/rubygems/rubygems/commit/da9d1d6a3f
This alternative really uses only the Gemfile, and can never end up
being absurd, because it will never be suggested when there's no
lockfile, and it suggests deleting the lockfile.
https://github.com/rubygems/rubygems/commit/5d154dd50e
If BUNDLE_PATH is configured to a symlinked path, installing gems with
symlinks would crash with an error like this:
```
Gem::Package::SymlinkError: installing symlink 'man/man0/README.markdown' pointing to parent path /usr/home/stevewi/srv/mail/lib/tools/.vendor/ruby/3.1.0/gems/binman-5.1.0/README.markdown of /srv/mail/lib/tools/.vendor/ruby/3.1.0/gems/binman-5.1.0 is not allowed
```
This commit fixes the problem by changing the bundle path to be the
realpath of the configured value, right after we're sure the path has
been created.
https://github.com/rubygems/rubygems/commit/3cd3dd142a
Apparently old versions of MacOS would set `GEM_HOME` to a `/System`
folder, and trying to create a file there raises `Errno::EROFS`.
We ignore the error. Any permission issues should be better handled
further down the line.
https://github.com/rubygems/rubygems/commit/ef90c071d0
This kind of error can happen when setting `GEM_HOME` to a path
under MacOS System Integrity Protection.
We ignore the error. Any permission issues should be better handled
further down the line.
https://github.com/rubygems/rubygems/commit/174cb66863
Instead of guessing on the culprit.
We actually have a helper, `Bundler.rm_rf`, with exactly the behavior
that we want:
* Allow the passed folder to not exist.
* No exception swallowing other than that.
https://github.com/rubygems/rubygems/commit/5fa3e6f04a
A while ago, we fixed resolution when using old dependency endpoints to
also consider metadata dependencies, by requesting the full gemspec from
the marsahaled index, which includes this information as opposed to
these old APIs. This has made resolution slower, but correct, but also
introduced the issue that some old marshaled gemspecs don't include the
`required_rubygems_version` field because they were created with a
RubyGems version that predates its addition.
Use a default value in this case.
https://github.com/rubygems/rubygems/commit/5dc94afcc0
Co-authored-by: Ilya Dudarenko <i.dudarenko@tinkoff.ru>
Check whether the current or previous frame is a Ruby frame in
call_trace_func and rb_tracearg_binding before attempting to
create a binding for the frame.
Fixes [Bug #18487]
Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>
If the block only accepts a single positional argument plus keywords,
then do not autosplat. Still autosplat if the block accepts more
than one positional argument in addition to keywords.
Autosplatting a single positional argument plus keywords made sense
in Ruby 2, since a final positional hash could be used as keywords,
but it does not make sense in Ruby 3.
Fixes [Bug #18633]
If TracePoint#enable is passed a block, it previously started
the trace on all threads. This changes it to trace only the
current thread by default. To limit the scope of the change,
the current thread is only used by default if target and
target_line are both nil. You can pass target_thread: nil
to enable tracing on all threads, to get the previous
default behavior.
Fixes [Bug #16889]
Check whether the current or previous frame is a Ruby frame in
call_trace_func before attempting to create a binding for the frame.
Fixes [Bug #18487]
Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>
cap-std, an underlying sandbox implementation of WASI in wasmtime, doesn't
allow to create a symlink to an absolute path to enforce sandbox restriction.
See also: 257867a1d3
When I run bundle install with BUNDLE_DEPLOYMENT=true in the environment
on a different platform than I usually do development, I get the
following output to the console (wrapped exactly as shown):
Your bundle only supports platforms ["x86_64-darwin-19"] but your local platform
is x86_64-linux. Add the current platform to the lockfile with `bundle lock
--add-platform x86_64-linux` and try again.
Because the way the message wraps, its not as simple as copying the
suggested command to the clipboard because it contains a newline:
$ bundle lock
Writing lockfile to [...]/Gemfile.lock
$ --add-platform x86_64-linux
Adding a newline right before the command forces the command in the
error message to be on the same line, which facilitates copy-pasting the
command in the message.
https://github.com/rubygems/rubygems/commit/4cf6989b11
Previously they had slightly different behavior when combined with
conservative updating flags.
The correct behavior is the `--update-strict` option, so `--script` now
does that, The `--update-strict` option is left there for now but I will
deprecate it later.
https://github.com/rubygems/rubygems/commit/ab42046229
If a Shipment has been delivered, there is no point in notifying the
buyer that the seller shipped. Instead, we should simply notify the
buyer that the shipment was delivered. This is relevant in cases where
the seller is late to mark a Shipment as shipped, so the first EasyPost
Tracker update marks it as delivered, or in cases where the seller
fails to mark as shipped and the buyer marks it as delivered.
This fixes a Shipment event handler so the buyer notification for
shipment is no longer invoked if the Shipment is already delivered.
https://github.com/rubygems/rubygems/commit/09c2cadc86
...with dashed gem name
In "bundle gem" command with dashed name gem (e.g. foo-bar) generates
`test/test_foo/bar.rb`, but this file contains undefined class `TestFoo`
and moreover, does not include in "bundle exec rake test" target.
Therefore, intentially the first test after gem created is fail, but in
case of gem name contains dash character is not.
The change doings...
(when "bundle gem foo-bar" called)
* create `test/test_foo_bar.rb`
* define `TestFooBar` class in `test/test_foo_bar.rb`
https://github.com/rubygems/rubygems/commit/5d9a69fc0f
Previously, the right hand side was always evaluated before the
left hand side for constant assignments. For the following:
```ruby
lhs::C = rhs
```
rhs was evaluated before lhs, which is inconsistant with attribute
assignment (lhs.m = rhs), and apparently also does not conform to
JIS 3017:2013 11.4.2.2.3.
Fix this by changing evaluation order. Previously, the above
compiled to:
```
0000 putself ( 1)[Li]
0001 opt_send_without_block <calldata!mid:rhs, argc:0, FCALL|VCALL|ARGS_SIMPLE>
0003 dup
0004 putself
0005 opt_send_without_block <calldata!mid:lhs, argc:0, FCALL|VCALL|ARGS_SIMPLE>
0007 setconstant :C
0009 leave
```
After this change:
```
0000 putself ( 1)[Li]
0001 opt_send_without_block <calldata!mid:lhs, argc:0, FCALL|VCALL|ARGS_SIMPLE>
0003 putself
0004 opt_send_without_block <calldata!mid:rhs, argc:0, FCALL|VCALL|ARGS_SIMPLE>
0006 swap
0007 topn 1
0009 swap
0010 setconstant :C
0012 leave
```
Note that if expr is not a module/class, then a TypeError is not
raised until after the evaluation of rhs. This is because that
error is raised by setconstant. If we wanted to raise TypeError
before evaluation of rhs, we would have to add a VM instruction
for calling vm_check_if_namespace.
Changing assignment order for single assignments caused problems
in the multiple assignment code, revealing that the issue also
affected multiple assignment. Fix the multiple assignment code
so left-to-right evaluation also works for constant assignments.
Do some refactoring of the multiple assignment code to reduce
duplication after adding support for constants. Rename struct
masgn_attrasgn to masgn_lhs_node, since it now handles both
constants and attributes. Add add_masgn_lhs_node static function
for adding data for lhs attribute and constant setting.
Fixes [Bug #15928]
[Feature #17881]
Works similarly to `method_added` but for constants.
```ruby
Foo::BAR = 42 # call Foo.const_added(:FOO)
class Foo::Baz; end # call Foo.const_added(:Baz)
Foo.autoload(:Something, "path") # call Foo.const_added(:Something)
```
Nobuyoshi Nakada
David Rodríguez
Alan Wu
Hiroshi SHIBATA
Jean Boussier
Benoit Daloze
moe
Jeremy Evans
Takuya Noguchi
Koichi Sasada
Kazuhiro NISHIYAMA
citrusmoose
Alan Wu
Ellen Marie Dash
Tim Smith
Bobby McDonald
Jun Aruga
Yuta Saito
Martin Dürst
Alex Gittemeier
Sven Schwyn
Dan Jensen
Ngan Pham
Yusuke Nakamura
Vyacheslav Alexeev
卜部昌平