On platform where searchs shared libraries by `PATH` environment
variable (i.e., Windows), the shared library is installed in
`bindir`. On other platforms, the library directory is directed
by `libdirname` indirectly.
`time_with_zone.zone.should == (time_with_zone - 60*60).zone` fails when
the time is immediately before the change of summer time.
https://rubyci.org/logs/rubyci.s3.amazonaws.com/unstable11s/ruby-master/log/20200328T232504Z.fail.html.gz
```
1)
Time#+ preserves time zone FAILED
Expected "CET" == "CEST"
to be truthy but was false
```
It is acceptable as it fails at most twice per year, but it would be
good to use near time objects to reduce the possibility.
https://github.com/ruby/ruby/runs/541455267
```
1)
RbConfig::CONFIG libdir/LIBRUBY_SO is the path to libruby and it exists if and only if ENABLE_SHARED FAILED
Expected File.exist? "d:/Ruby26-x64/lib/x64-msvcrt-ruby260.dll"
to be truthy but was false
D:/a/ruby/ruby/src/spec/ruby/library/rbconfig/rbconfig_spec.rb:46:in `block (3 levels) in <top (required)>'
D:/a/ruby/ruby/src/spec/ruby/library/rbconfig/rbconfig_spec.rb:4:in `<top (required)>'
```
This freezes the clone even if the receiver is not frozen. It
is only for consistency with freeze: false not freezing the clone
even if the receiver is frozen.
Because Object#clone is now partially implemented in Ruby and
not fully implemented in C, freeze: nil must be supported to
provide the default behavior of only freezing the clone if the
receiver is frozen.
This requires modifying delegate and set, to set freeze: nil
instead of freeze: true as the keyword parameter for
initialize_clone. Those are the two libraries in stdlib that
override initialize_clone.
Implements [Feature #16175]
As a semantics, Hash#each yields a 2-element array (pairs of keys and
values). So, `{ a: 1 }.each(&->(k, v) { })` should raise an exception
due to lambda's arity check.
However, the optimization that avoids Array allocation by using
rb_yield_values for blocks whose arity is more than 1 (introduced at
b9d2960337 and some commits), seemed to
overlook the lambda case, and wrongly allowed the code above to work.
This change experimentally attempts to make it strict; now the code
above raises an ArgumentError. This is an incompatible change; if the
compatibility issue is bigger than our expectation, it may be reverted
(until Ruby 3.0 release).
[Bug #12706]
Previously, if an object has a singleton class, and you call
Object#method on the object, the resulting string would include
the object's singleton class, even though the method was not
defined in the singleton class.
Change this so the we only show the singleton class if the method
is defined in the singleton class.
Fixes [Bug #15608]
When providing a single array to a block that takes a splat, pass the
array as one argument of the splat instead of as the splat itself,
even if the block also accepts keyword arguments. Previously, this
behavior was only used for blocks that did not accept keywords.
Implements [Feature#16166]
FreeBSD's GETNAMEINFO(3) says:
> If a link-layer address or UNIX-domain address is passed to
> getnameinfo(), its ASCII representation will be stored in host. The
> string pointed to by serv will be set to the empty string if non-NULL;
> flags will always be ignored.
Android seems to behave like FreeBSD.
This behavior was deprecated in 2.7 and scheduled to be removed
in 3.0.
Calling yield in a class definition outside a method is now a
SyntaxError instead of a LocalJumpError, as well.
These specs were probably added in the commit to fully
separate keyword arguments after the release of 2.7.0, but
apparently not tested on 2.7 before hand. The enclosing
ruby_version guard for these specs limits them to 2.7.
This removes the warning that was added in
3802fb92ff, and switches the behavior
so that the eval does not use the binding's __FILE__ and __LINE__
implicitly.
Fixes [Bug #4352]
* MinGW - skip spec in spec/ruby/optional/capi/thread_spec.rb
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
stops/freezes spec tests
See https://bugs.ruby-lang.org/issues/16265
* MinGW - skip test test/resolv/test_dns.rb
Test times out in CI (both AppVeyor & Actions), cannot repo locally
* MinGW - skip test test/ruby/test_thread_queue.rb
* Add Actions mingw.yml
We want to introduce consistency and better compatibility with unixen,
but the Windows APIs doues not have consistency fundamentally and
we can not found any logical way...
This reverts commit 61aff0cd18.
`* 1e6` makes a spurious result about floating point number's precision.
```
irb(main)[01:0]> 16.028
=> 16.028
irb(main)[02:0]> (16.028 * 1e6)
=> 16027999.999999998
```
Asynchronous events such as signal trap, finalization timing,
thread switching and so on are managed by "interrupt_flag".
Ruby's threads check this flag periodically and if a thread
does not check this flag, above events doesn't happen.
This checking is CHECK_INTS() (related) macro and it is placed
at some places (laeve instruction and so on). However, at the end
of C methods, C blocks (IMEMO_IFUNC) etc there are no checking
and it can introduce uninterruptible thread.
To modify this situation, we decide to place CHECK_INTS() at
vm_pop_frame(). It increases interrupt checking points.
[Bug #16366]
This patch can introduce unexpected events...
This removes the related tests, and puts the related specs behind
version guards. This affects all code in lib, including some
libraries that may want to support older versions of Ruby.
This removes the security features added by $SAFE = 1, and warns for access
or modification of $SAFE from Ruby-level, as well as warning when calling
all public C functions related to $SAFE.
This modifies some internal functions that took a safe level argument
to no longer take the argument.
rb_require_safe now warns, rb_require_string has been added as a
version that takes a VALUE and does not warn.
One public C function that still takes a safe level argument and that
this doesn't warn for is rb_eval_cmd. We may want to consider
adding an alternative method that does not take a safe level argument,
and warn for rb_eval_cmd.
Not sure what is happening, but spec/ruby/security/cve_2018_6914_spec.rb
fails on macOS.
https://github.com/ruby/ruby/runs/294462511#step:10:134
I suspect that the state of a directory is weird immediately after it is
created (not writable or even world writable?). This change tries to
make sure that ENV["TMPDIR"] is actually used by Dir.tmpdir.
Since the current working directory is not involved in `Tempfile`
and `Dir.mktmpdir` (except for the last resort), it is incorrect
to derive the traversal path from it. Also, since the rubyspec
temporary directory is created under the build directory, this is
not involved in the target method. Fixed sporadic errors in
test-spec.
Fiber#transfer previously made it impossible to resume the fiber
if it was transferred to (no resuming the target of Fiber#transfer).
However, the documentation specifies that you cannot resume a fiber
that has transferred to another fiber (no resuming the source of
Fiber#transfer), unless control is transferred back.
Fix the code by setting the transferred flag on the current/source
fiber, and unsetting the transferred flag on the target fiber.
Fixes [Bug #9664]
Fixes [Bug #12555]
return directly in class/module is an error, so return in
proc in class/module should also be an error. I believe the
previous behavior was an unintentional oversight during the
addition of top-level return in 2.4.
Some warnings are because the @o.rb_scan_args call doesn't
include keyword arguments, but the first argument is passed to
rb_scan_args may have a last hash treated as keywords. Those
should be handled using rb_scan_args_kw on Ruby 2.7.
Other warnings are for the deprecated rb_scan_args behavior to
split option hashes or treat a nil argument as an option hash.
Those warnings should just be suppressed.
This makes it consistent with calling private attribute assignment
methods, which currently is allowed (e.g. `self.value =`).
Calling a private method in this way can be useful when trying to
assign the return value to a local variable with the same name.
[Feature #11297] [Feature #16123]
7340: Fix bundle clean issue r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `bundle clean` is crashing under some conditions.
### What was your diagnosis of the problem?
My diagnosis was that sometimes (when the bundle includes git sourced gems with extensions), it assumes that some paths exist, but they don't.
### What is your fix for the problem, implemented in this PR?
My fix is to ignore those paths.
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the issue.
Fixes#7338.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit b007fde67c77c1f15f13b97eda186644c2a2be04)
https://github.com/bundler/bundler/commit/3766053507
Calling some syscall functions such as Dir.chroot causes SIGSYS instead
of EPERM on Android.
This change skips all tests that stops the test-suite run.
* These seem to consistenly pass already
* Show actual command when running `make test-bundler`
Current the setup command that installs the necessary gems for testing
bundler was printed, but not the actual command that runs the tests.
That was a bit confusing.
* Borrow trick from setproctitle specs
* A title that long doesn't get set sometimes
No idea why, but the test doesn't need that the title is that long.
* Fix most gem helper spec ruby-core failures
* Fix the rest of the gem helper failures
* Fix version spec by improving the assertion
* Remove unnecessary `BUNDLE_RUBY` environment var
We can use `RUBY` when necessary, and `BUNDLE_RUBY` is not a good name
because bundler considers `BUNDLE_*` variables as settings.
* Rename `BUNDLE_GEM` to `GEM_COMMAND`
This is more descriptive I think, and also friendlier for bundler
because `BUNDLE_` env variables are interpreted by bundler as settings,
and this is not a bundler setting.
This fixes one bundler spec failure in config specs against ruby-core.
* Fix quality spec when run in core
Use the proper path helper.
* Fix dummy lib builder to never load default gems
If a dummy library is named as a default gem, when requiring the library
from its executable, the default gem would be loaded when running from
core, because in core all default gems share path with bundler, and thus
they are always in the $LOAD_PATH. We fix the issue by loading lib
relatively inside dummy lib executables.
* More exact assertions
Sometimes I have the problem that I do some "print debugging" inside
specs, and suddently the spec passes. This happens when the assertion is
too relaxed, and the things I print make it match, specially when they
are simple strings like "1.0" than can be easily be part of gem paths
that I print for debugging.
I fix this by making a more exact assertion.
* Detect the correct shebang when ENV["RUBY"] is set
* Relax assertion
So that the spec passes even if another paths containing "ext" are in
the load path. This works to fix a ruby-core issue, but it's a better
assertion in general. We just want to know that the extension path was
added.
* Use folder structure independent path helper
It should fix this spec for ruby-core.
* Fix the last failing spec on ruby-core
* Skip `bundle open <default_gem>` spec when no default gems
If we use system bundler, when booting the "outermost" bundler process,
bundler will save the path to the system bundler in BUNDLE_BIN_PATH, and
use it again when booting the "innermost" bundler process (`bundle exec
echo foo`).
That means that second process will use the system bundler path again.
However, we have `-rsupport/hax` in RUBYOPT, so that file will load from
the local copy of bundler, and that file will load `bundler/version`
from the project (not from system), because -Ilib is in the LOAD_PATH.
That will end up causing redefinition errors because the same constant
will be loaded from two different locations.
In general, this is expected behavior, normally you will wrap the
process with `Bundler.with_original_env` to reset the environment.
However, the easiest fix here is to not use system bundler, because it's
not really necessary and thus doesn't help the readability of the spec.
https://github.com/bundler/bundler/commit/a3d72a34ab
Previously `bundle doctor` would fail on any bundle that does not
include git gems or plugins. This is because the previously used
`Bundler.home` does not exist unless the bundle includes git gems or
plugins. For example, with `bundle config set path .bundle`, it points
to which does not exist unless this kind of gems exist in the Gemfile.
The name `Bundler.home` is really unfortunate, it should probably be
have more descriptive name, and be private. But for now I just want to
make `bundle doctor` usable.
https://github.com/bundler/bundler/commit/5531a18c1e
卜部昌平
Nobuyoshi Nakada
Benoit Daloze
Yusuke Endoh
Takashi Kokubun
Jeremy Evans
Jean Boussier
Kazuhiro NISHIYAMA
dependabot[bot]
Hiroshi SHIBATA
Sutou Kouhei
MSP-Greg
Alan Wu
NAKAMURA Usaku
NARUSE, Yui
David Rodríguez
Koichi Sasada
Jean byroot Boussier
Jun Aruga
Kenichi Kamiya
git
Sutou Kouhei
Dylan Thacker-Smith
Bundlerbot
Samuel Giddins
Takayuki Nakata
lolwut
Zehan Zhao
David Stosik