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
The other way, in particular matching a substring in the gemspec
summary, is brittle and no longer used since Ruby 2.0.
This needed rewriting the specs that depended on that way.
https://github.com/rubygems/rubygems/commit/059dbfa971
The spec was just faking an installed gemspec without any installed gem
backing it up, resulting in `bundle install` claiming that the gem was
already installed when it was not.
https://github.com/rubygems/rubygems/commit/c35531d1c7
In 2021, Ruby 2.5 and older are EOL.
We can set the default required Ruby version to 2.6.0 to
encourage people to use newer Ruby.
If the command is executed with old Ruby, it falls back to 2.3.0.
It's still possible to create a gem for older Ruby just by changing
two lines of code (one in gemspec and another is in rubocop.yml).
We want to update the original repo, not a fresh one.
This went undetected because the `git commit` command inside the
`update_git` method ignores failures, and in this case it was failing
because all files are untracked in the new repo.
I will fix that later but for now fix the typo.
https://github.com/rubygems/rubygems/commit/c889f1d715
The glob information was not specified in the string representation for
a source, which led to non-deterministic behaviour when generating the
lockfile, since sources are sorted by this value.
https://github.com/rubygems/rubygems/commit/493b880abc
Previously, if an autoload failed (the file was loaded, but the
constant was not defined by the autoloaded file). Ruby will try
to autoload again if you delete the autoloaded file from
$LOADED_FEATURES. With this change, the autoload and the
constant itself are removed as soon as it fails.
To handle cases where multiple threads are autoloading, when
deleting an autoload, handle the case where another thread
already deleted it.
Fixes [Bug #15790]
The error had not be caught be specs because `bundle install` was
returning a zero exit code when plugin installation errors happened. So
I fixed that issue too.
https://github.com/rubygems/rubygems/commit/90cde87856
As part of a recent bug fix where bundler was accidentally hitting the
network when not supposed to, I made some refactoring, and the commit I'm
reverting here
(d74830d00b)
was some cleanup that those refactorings allowed according to "past me".
That was completely wrong, `bundle check` should never consider cached
gems, only installed gems, so the code that was removed was necessary.
https://github.com/rubygems/rubygems/commit/5483e98305
Use the `git branch --list` rather than the `git branch -l` for better
compatibility. Because the `git branch -l` is used to create a new branch in
Git version < 2.20.0.
https://github.com/rubygems/rubygems/commit/eac5be7d06
When setting the `RUBYGEMS_GEMDEPS` environment variable to allow
skipping `bundle exec`, `bundler` will print a warning about potential
incompatibility.
Initially the `RUBYGEMS_GEMDEPS` variable used a completely different
(re)implementation of `bundler` functionality. That implementation was
not battle tested and could potentially differ in behaviour from what
`bundler` does. That's why print a warning.
However, these days, all `rubygems` does when `RUBYGEMS_GEMDEPS` is set
is to require `bundler/setup`, so there's no risk of any
incompatibility, since that's just plain `bundler`.
https://github.com/rubygems/rubygems/commit/bbddc27016
When printing sources inside these error messages, it's useful to only
consider the current state of the source. For example, when requiring
`bundler/setup`, the source shouldn't be configured to be able to hit
the network, so the error message should only mention "locally installed
gems" to make that more clear.
https://github.com/rubygems/rubygems/commit/30eb14f853
In the case of path sources, the path the source is pointing to should
be added directly to the `$LOAD_PATH` without any modifications.
https://github.com/rubygems/rubygems/commit/d3bba936f0
Co-authored-by: Daniel Niknam <mhmd.niknam@gmail.com>
TSort was released as a library so we can install it, and also other
gems that are loaded by the spec. Also, Ruby on Windows apparently loads
fiddle 1.0.6, so we need to also install that to make that not fail.
https://github.com/rubygems/rubygems/commit/2b8dcab99e
Call `IOSpecs.io_fixture` with the default encoding explicitly.
`IOSpecs.closed_io` calls the method without optional `mode` which
is set to UTF-8 by default, while the default external encoding
depends on the locale environment variables.
Mashalling a closed IO object raised "closed stream (IOError)" before instead of TypeError.
This changes IO#(in|ex)ternal_encoding to still return the encoding even if the underlying FD is closed.
Fixes bug #18077
This updates the trace instructions to directly dispatch to
opt_send_without_block. So this should cause no slowdown in
non-trace mode.
To enable the tracing of the optimized methods, RUBY_EVENT_C_CALL
and RUBY_EVENT_C_RETURN are added as events to the specialized
instructions.
Fixes [Bug #14870]
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
* Hide read function warning in string_spec_RSTRING_PTR_read function
* The type of `read` may be `ssize_t`
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
This changes Thread::Location::Backtrace#absolute_path to return
nil for methods/procs defined in eval. If the realpath of an iseq
is nil, that indicates it was defined in eval, in which case you
cannot use RubyVM::AbstractSyntaxTree.of.
Fixes [Bug #16983]
Co-authored-by: Koichi Sasada <ko1@atdot.net>
Bundler has deprecated gemfiles without a global source and this feature
is now obsolete. `Bundler::Definition#has_rubygems_remotes?` is removed
because it's not used anymore.
https://github.com/rubygems/rubygems/commit/d29dd2cb7b
`check_rubygems_source_safety` is responsible for:
1. if there are multiple global sources
- for bundle 3.x raise an error
- for bundle 2.x print a warning
2. print a warning if there is no explicit global source
The second responsibility was added recently and now the logic could be
extracted to improve readability. Conditions are still live in the `check_rubygems_source_safety` method
since we don't want to call both functions always and that would help us achieve that.
https://github.com/rubygems/rubygems/commit/f3d7e946ee
Raise a warning when parsing a Gemfile and it doesn't have a global source. Gemfiles like this, specially now that rubygems sources are are no longer merged into a single source for security, are very confusing because they generate a different lockfile depending on the gems you have locally installed. This is because bundler always use an implicit global source that defaults to locally installed gems.
https://github.com/rubygems/rubygems/commit/b7523ad21c
This method is created to tell whether any global source exist in the object or not and it will be used by `Bundler:Dsl` to print a warning if no global source has been defined in the Gemfile.
https://github.com/rubygems/rubygems/commit/422fec4438
This method is created to tell whether any remote exist in the object or not and it will be used by `Bundler:SourceList` to tell if a global source has been defined implicitly or not.
https://github.com/rubygems/rubygems/commit/47e3ff0e47
The is the previous intentional behaviour until
ca0676cb1c.
In my opinion, that previous behaviour was better and should be
restored, because we want our users to always see warnings and fix them.
And the original issue that motivated the change is fixable by other
means, namely through `BUNDLE_SILENCE_ROOT_WARNING`, or through
`BUNDLE_SILENCE_DEPRECATIONS` in general. Finally, the --quiet option is
still documented as "only print errors and warnings".
So this PR essentially reverts
ca0676cb1c
for the above reasons.
https://github.com/rubygems/rubygems/commit/35f2254dfc
We'll be removing the warning about no gem sources, so this spec will no
longer test that warnings are hidden by `--quiet`.
Test that in another way so that we don't lose the coverage when we
drop the specific warning about no gem server sources.
https://github.com/rubygems/rubygems/commit/cce4f86d28
A fresh `gem install` might not reproduce the exact `bundle install`
environment that originally caused the error. It also makes it harder
for the user to troubleshoot the error since she needs to run a separate
command.
Instead, show the original error and backtrace directly.
https://github.com/rubygems/rubygems/commit/49c2abfec6
To mimic built-in rubygems behaviour, only thing that should be
approximated is the lockfile version. Other alternatives like
`BUNDLER_VERSION` should be respected exactly.
https://github.com/rubygems/rubygems/commit/dbd667d4bc
Ruby 1.9.2 removed "." from LOAD_PATH for robustness and security reasons.
This code was introduced by 56fc830e19 commit
to helping users understand the issue and had a guard condition to include the message for `RUBY_VERSION >= "1.9"`.
However, the guard condition was removed as part of the "Ruby version leftover" cleanup by
8c9cf76e41
Ruby 1.9 development was ended a long time ago and this message is not useful anymore.
https://github.com/rubygems/rubygems/commit/a23609b15a
The existing interrupt handling using `SharedHelpers.trap` fails when the previous
handler for a signal is not callable (for example, when it is the string "DEFAULT").
Instead, we now handle interrupts by aborting the process when worker threads are
running, and restore the previous handler after worker threads are finished.
Fixes#4764.
https://github.com/rubygems/rubygems/commit/b9f455d487
```
1)
The -W command line option with :no-experimental suppresses experimental warnings FAILED
Expected "" =~ /is experimental/
to be truthy but was nil
```
it turns out that running `bundle plugin uninstall some-plugin` would remove that plugin from the list of hooks, but if the list of hooks for an event was now empty, we would serialize the empty array into yaml as an empty single bullet item. which would then get unserialized as a plugin with the name empty string. which we would then try to load and explode. 😬https://github.com/rubygems/rubygems/commit/545ebba9a5
When a development dependency was duplicated inside the gemspec and
Gemfile with the same requirements, we went from printing a warning to
removing the gem altogether.
This change makes it not print a warning, but don't remove the gem
either.
https://github.com/rubygems/rubygems/commit/8bb2488131
- Limit Unicode version 12.1.0 to Ruby versions 2.6.3 - 3.0
- Check that Ruby version 3.1 has Unicode version 13.0.0
- Limit Unicode Emoji version 12.1 to Ruby versions 2.7 - 3.0
- Check that Ruby version 3.1 has Unicode Emoji version 13.0
Depending on the float range, there could be an off-by-one error,
where the last result that should be in the range was missed. Fix
this by checking if the computed value for the expected value
outside the range is still inside the range, and if so, increment
the step size.
Fixes [Bug #16612]
Ruby uses a recursive algorithm for handling control/meta escapes
in strings (read_escape). However, the equivalent code for regexps
(tokadd_escape) in did not use a recursive algorithm. Due to this,
Handling of control/meta escapes in regexp did not have the same
behavior as in strings, leading to behavior such as the following
returning nil:
```ruby
/\c\xFF/ =~ "\c\xFF"
```
Switch the code for handling \c, \C and \M in literal regexps to
use the same code as for strings (read_escape), to keep behavior
consistent between the two.
Fixes [Bug #14367]
* Run nmake check on Actions
* Skip tests not working in mswin GitHub Actions
* Override TEMP
* Revert "Skip tests not working in mswin GitHub Actions"
This reverts commit 544d2575fcdf23ae63cd25aa03fce10c28b259f2.
* Revert "Revert "Skip tests not working in mswin GitHub Actions""
This reverts commit e1f8ad7862c9c4be52dc6e1031a004621eb07e6e.
* Fix timeouts
* Skip some more broken tests
* Update windows.yml
* Add a guard for rbasic_spec
* Revert "Update windows.yml"
This reverts commit bc9694b6b3b9594d406378d15ca11723fb052bc8.
* Skip the ensure clause
* Simplify the ensure
* Add test cases for Enumerable#tally with hash argument
* Add ruby/spec for Enumerable#tally with hash argument
* Fix Enumerable#tally does not update given frozen hash
* Add test cases for Enumerable#tally with hash convertible arguments
* Fix SEGV when Enumerable#tally takes non Hash convertible
* FIx cosmetic damage enum.c
* https://github.com/ruby/ruby/runs/1994688198
ruby 3.1.0dev (2021-02-27T16:42:17Z master 8305a48413) [x64-mingw32]
C-API Thread function rb_thread_call_without_gvl runs a C function with the global lock unlocked and unlocks IO with the generic RUBY_UBF_IO
Example took longer than the configured timeout of 60.0s
The documentation already specifies that they strip whitespace
and defines whitespace to include null.
This wraps the new behavior in the appropriate guards in the specs,
but does not specify behavior for previous versions, because this
is a bug that could be backported.
Fixes [Bug #17467]
http://ci.rvm.jp/logfiles/brlog.trunk-test.20210216-182358
```
1)
$LOAD_PATH.resolve_feature_path raises LoadError if feature cannot be found FAILED
Expected LoadError but no exception was raised (nil was returned)
/tmp/ruby/v3/src/trunk-test/spec/ruby/language/predefined_spec.rb:1275:in `block (3 levels) in <top (required)>'
/tmp/ruby/v3/src/trunk-test/spec/ruby/language/predefined_spec.rb:1259:in `block in <top (required)>'
/tmp/ruby/v3/src/trunk-test/spec/ruby/language/predefined_spec.rb:1258:in `<top (required)>'
```
On macOS with EditLine:
```
$ ruby -r readline -e 'Readline.readline("> "); p Readline::VERSION' < /dev/null
"EditLine wrapper"
```
On Linux with GNU readline:
```
$ ruby -r readline -e 'Readline.readline("> "); p Readline::VERSION' < /dev/null
> "8.0"
```
iff means if and only if, but readers without that knowledge might
assume this to be a spelling mistake. To me, this seems like
exclusionary language that is unnecessary. Simply using "if and only if"
instead should suffice.
because the name "MJIT" is an internal code name, it's inconsistent with
--jit while they are related to each other, and I want to discourage future
JIT implementation-specific (e.g. MJIT-specific) APIs by this rename.
[Feature #17490]