...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)
```
This allows for the following syntax:
```ruby
def foo(*)
bar(*)
end
def baz(**)
quux(**)
end
```
This is a natural addition after the introduction of anonymous
block forwarding. Anonymous rest and keyword rest arguments were
already supported in method parameters, this just allows them to
be used as arguments to other methods. The same advantages of
anonymous block forwarding apply to rest and keyword rest argument
forwarding.
This has some minor changes to #parameters output. Now, instead
of `[:rest], [:keyrest]`, you get `[:rest, :*], [:keyrest, :**]`.
These were already used for `...` forwarding, so I think it makes
it more consistent to include them in other cases. If we want to
use `[:rest], [:keyrest]` in both cases, that is also possible.
I don't think the previous behavior of `[:rest], [:keyrest]` in
the non-... case and `[:rest, :*], [:keyrest, :**]` in the ...
case makes sense, but if we did want that behavior, we'll have to
make more substantial changes, such as using a different ID in the
... forwarding case.
Implements [Feature #18351]
These specs were monkeypatching `RUBY_VERSION`, but that obviously
doesn't change the running ruby to behave any different.
The removal of some features, in particular, `String#untaint`, made
these specs fail, because untaint is no longer available under ruby-core
and bundler calls `untaint` when `RUBY_VERSION` is less than "2.7",
which these specs were overwriting it to be.
Rewrite these specs to not overwrite `RUBY_VERSION`, but still test the
same things.
https://github.com/rubygems/rubygems/commit/e8c7b92901
The `BUNDLE_` prefix should be reserved to first class settings that
should be listed when running `bundle config`. This one is just a hacky
environment variable that has not corresponding documented setting.
https://github.com/rubygems/rubygems/commit/7e255c5058
fix this failure:
```
configure ... cppflags=-DMJIT_FORCE_ENABLE
...
make test-spec
1)
The -v command line option when used alone prints version and ends FAILED
Expected
"ruby 3.1.0dev (2021-12-18T10:10:42Z master 78c175280b) +MJIT [x86_64-linux]
"
to include "ruby 3.1.0dev (2021-12-18T10:10:42Z master 78c175280b) [x86_64-linux]"
/tmp/ruby/v3/src/trunk-mjit-wait/spec/ruby/command_line/dash_v_spec.rb:9:in `block (3 levels) in <top (required)>'
/tmp/ruby/v3/src/trunk-mjit-wait/spec/ruby/command_line/dash_v_spec.rb:4:in `<top (required)>'
```
http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3759943
If we are resolving a dependency against a particular platform, and
there are no platform specific variants of the candidates that match
that platform, we should not consider those candidates.
https://github.com/rubygems/rubygems/commit/f6077fe27d
Linux can allow to bind port 1 to user.
And `ip_unprivileged_port_start` is 0 on [lima](https://github.com/lima-vm/lima) default vm.
```
1)
Socket#bind on SOCK_DGRAM socket raises Errno::EACCES when the current user does not have permission to bind FAILED
Expected Errno::EACCES but no exception was raised (0 was returned)
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:38:in `block (4 levels) in <top (required)>'
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:4:in `<top (required)>'
2)
Socket#bind on SOCK_STREAM socket raises Errno::EACCES when the current user does not have permission to bind FAILED
Expected Errno::EACCES but no exception was raised (0 was returned)
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:79:in `block (4 levels) in <top (required)>'
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:44:in `<top (required)>'
3)
Socket#bind using IPv4 using a packed socket address raises Errno::EACCES when the user is not allowed to bind to the port FAILED
Expected Errno::EACCES but no exception was raised (0 was returned)
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:119:in `block (6 levels) in <top (required)>'
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:85:in `<top (required)>'
4)
Socket#bind using IPv6 using a packed socket address raises Errno::EACCES when the user is not allowed to bind to the port FAILED
Expected Errno::EACCES but no exception was raised (0 was returned)
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:119:in `block (6 levels) in <top (required)>'
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:85:in `<top (required)>'
```
Test and ensure "false" is handled
Don't use yield_self to operate on autorequire
Remove duplicate autorequire
Add banner to require option
Don't use json to break down require params
Pass linter
https://github.com/rubygems/rubygems/commit/a4f2f8ac17
This way, if some default gem has been required before bundler, and
rubygems has enhanced the `$LOAD_PATH` to use the latest version in the
system, further requires of that default gem after bundler has been
activated will use the same version and don't cause redefinition
warnings or worse problems derived from the fact of mixing up two
different versions. That, unless the gem is a `Gemfile` dependency. In
that case, we'll get a mismatch error anyways as we do now.
This fix doesn't mean that all default gems internally used by
bundler/rubygems are now supported inside `Gemfile`'s. That should be
handled case by case, but it will now bite people only when they try to
add the gem to their `Gemfile`, not before.
https://github.com/rubygems/rubygems/commit/7325530547
This block of code already wraps file operations with
`SharedHelpers.filesystem_access`, which rescues and re-raises more
friendly errors. Also, I'm not fully sure creating a temporary directory
can end up raising an `Errno::EACCES` error from reading `tmpdir`
sources. Finally, this rescue block apparently leads to some false
positives when firewall is blocking the ruby executable on Windows, or
at least that's what we've got reported.
In any case, I think it's best to let the original error be raised.
https://github.com/rubygems/rubygems/commit/f7dbe54404
Since we no longer have multiple global sources, each top level dependency is
always pinned to a single source, so it makes little sense to talk about
adding or removing a source. Instead, source changes always mean to
change the source one or more dependencies are pinned to. This logic can
now be much simpler.
https://github.com/rubygems/rubygems/commit/f1d33fa0df
We have two representations of a source. Once used for sorting, which
should not depend on the source's state, but solely on its static
information, like remotes. Another one used for error and informational
messages, which should properly inform about the exact state of the
source when the message is printed.
This commit makes the latter be the default implementation of `to_s`, so
that error and informational messages are more accurate by default.
https://github.com/rubygems/rubygems/commit/b5f2b88957
Since the default requirement in rubygems is ">= 0", it was failing to
match 0 prereleases. Changing the default globally to be ">= 0.a"
instead is a major refactoring that's quite tricky to make backwards
compatible, so I'm special casing this where needed for now to fix the
regression.
https://github.com/rubygems/rubygems/commit/68fe37937c
Previously, each of these methods returned self, but it is
more useful to return arguments, to allow for simpler method
decorators, such as:
```ruby
cached private def foo; some_long_calculation; end
```
Where cached sets up caching for the method.
For each of these methods, the following behavior is used:
1) No arguments returns nil
2) Single argument is returned
3) Multiple arguments are returned as an array
The single argument case is really the case we are trying to
optimize for, for the same reason that def was changed to return
a symbol for the method.
Idea and initial patch from Herwin Quarantainenet.
Implements [Feature #12495]
Calling `Bundler.definition.specs` will memoize materialized specs.
However, requiring `bundler/setup` will end up materializing the same
set of specs, but not memoize them.
This change makes things consistent.
https://github.com/rubygems/rubygems/commit/e4c2b52824
We have a quality spec that check for debugger statements. Rubocop has a
cop that tests for the same thing. As such it makes sense to remove the
spec and activate the cop.
https://github.com/rubygems/rubygems/commit/dc1eb6eec5
Even if it's newer than the running versions. Dev versions are not
released to rubygems.org, so the warning message suggests a command that
doesn't work. And dev versions are currently non deterministic
(2.3.0.dev can be many different versions), so the warning doesn't
really make sense at the moment.
https://github.com/rubygems/rubygems/commit/6f31af27ef
We can skip most stuff in `Gem::RemoteFetcher#download`, and use
`Gem::RemoteFetcher#update_cache_path` directly.
This has the benefit of allowing us to remove some workarounds to
support several rubygems versions, but also allows us to pass the target
folder where the gem should be downloaded directly and skip the logic
inside `Gem::RemoteFetcher#download` to infer the cache path. This will
be useful later to fix some issues with the `global_gem_cache` feature
flag.
https://github.com/rubygems/rubygems/commit/8fe74a77e4
Previously they were printing the original command that was run, and
telling the user to rerun it. However, the command sometimes would not
match the exact command that was run (for example, when using the
`--local` flag), and in any case, it's simpler and more useful to print
the underlying error anyways.
https://github.com/rubygems/rubygems/commit/5bc0d51b58
In case we have a corrupted lockfile that claims to support a platform, but
it's missing platform specific gems for it, bundler has a check that
detects the situation and forces a re-resolve. The result of this check
is kept under the `@locked_specs_incomplete_for_platformn` instance
variable in `Definition`.
The installer, however, calls `Definition#nothing_changed?` before this
instance variable has been filled, so the result of it is actually
incorrect here since it will claim that nothing has changed, but
something has changed (locked specs are incomplete for the current
platform).
The consequence of this incorrect result is that the installer thinks it
can go on without re-resolving, resulting in the incomplete resolution
from the lockfile being used, and in a crash being triggered due to
that.
The solution is to make sure the `@locked_specs_incomplete_for_platform`
instance variable is filled before `nothing_changed?` gets called.
Moving it to `initialize` makes the most sense, not because it's the
best place for it (we can refactor this later), but because all of the
other "outdated definition" checks are already set there.
https://github.com/rubygems/rubygems/commit/708afdd789
Yusuke Nakamura
Hiroshi SHIBATA
David Rodríguez
Kazuhiro NISHIYAMA
Jeremy Evans
Jean Boussier
Vyacheslav Alexeev
Benoit Daloze
Nobuyoshi Nakada
卜部昌平
Takashi Kokubun
Koichi Sasada
Simon Fish
Josef Šimánek
ooooooo-q
Yusuke Endoh
haruuzion
Frederik Dudzik
Frederik Dudzik
Alan Wu
Peter Zhu
180909
TSUYUSATO Kitsune