We're not fully in control of this folder, even when running our own
tests, because MJIT creates some temp folders there when invoking GC.
This bite tests running in ruby-core when making the behavior of
`FileUtils.rm_rf` more strict, because these extra files could not be
removed.
Since this was originally added due to some failures on systems with non
standard permissions on tmp folders, but I can no longer reproduce
those, I'll remove it.
d2f21596ee
This reverts commit 7bdb999d0f.
I think I confirmed the mechanism. GCC (invoked by MJIT) creates a
temporary file in TMPDIR, which prevents rm_rf from removing the
directory.
http://ci.rvm.jp/results/trunk-mjit@phosphorus-docker/4213386
It's failing with:
rm: cannot remove '/tmp/ruby/v3/build/trunk-mjit/tmp/test_rubygems_20220827-13666-ii8lcp': Directory not empty
rm: cannot remove '/tmp/ruby/v3/build/trunk-mjit/tmp/test_rubygems_20220827-13666-fy77y1': Directory not empty
I'd like to make sure the following `ENV.replace` is called and see if
there's any other issues.
catch_excep_t is a field that exists for MJIT. In the process of
rewriting MJIT in Ruby, I added API to convert 1/0 of _Bool to
true/false, and it seemed confusing and hard to maintain if you
don't use _Bool for *_p fields.
It hangs even after a retry
7966439530
We contacted GitHub Suppport about this before, and we concluded that
the problem is on our end. Unfortunately we don't have a bandwidth to
fix this MinGW problem, so until we get to work on it, this should be
just skipped to avoid a sporadic CI timeout.
... instead of any StandardError.
To behave like the standard `rm` command, it should only ignore
exceptions about not existing files, not every exception. This should
make debugging some errors easier, because the expectation is that `rm
-rf` will succeed if and only if, all given files (previously existent
or not) are removed. However, due to this exception swallowing, this is
not always the case.
From the `rm` man page
> COMPATIBILITY
>
> The rm utility differs from historical implementations in that the -f
> option only masks attempts to remove non-existent files instead of
> masking a large variety of errors.
fa65d676ec
Co-Authored-By: David Rodríguez <deivid.rodriguez@riseup.net>
The ensure in postorder_traverse was added for [Bug #6756].
The intention was to try to delete the parent directory if it failed to
get the children. (It may be possible to delete the directory if it is
empty.)
However, the ensure region rescue'ed not only "failure to get children"
but also "failure to delete each child". Thus, the following raised
Errno::ENOTEMPTY, but we expect it to raise Errno::EACCES.
```
$ mkdir foo
$ touch foo/bar
$ chmod 555 foo
$ ruby -rfileutils -e 'FileUtils.rm_rf("foo")'
```
This changeset narrows the ensure region so that it rescues only
"failure to get children".
ec5d3b84ea
The test was added for [Bug #6756]. The ticket insisted
`FileUtils.rm_rf` should delete an empty directory even if its
permission is 000. However, the test tried to delete a directory with
permission 700.
d6c2ab2c01
Attempting to install a gem published as both *-linux and *-linux-musl
results in the incorrect gem being picked up, causing build failures due
to binary incompatibility. This is caused by the `nil` wildcard
swallowing the libc information upon version comparison.
Handle the linux case by performing only non-wildcard equality on the
version and asserting 'gnu' and nil equivalence, while preserving the
current behaviour for other OSes.
9eead86abc
Co-authored-by: Loic Nageleisen <loic.nageleisen@gmail.com>
On past versions there were observed cases of inconsistencies when some
platforms were re-parsed.
Ensure that a platform's string representation parses again in a
platform object equal to the original.
6da35ee93c
The current MJIT relies on SIGCHLD and fork(2) to be performant, and
it's something mswin can't offer. You could run Linux MJIT on WSL
instead.
[Misc #18968]
Based on c95e7e5329
Among other things, this fixes calling visibility methods (public?,
protected?, and private?) on them. It also fixes #owner to show the
class the zsuper method entry is defined in, instead of the original
class it references.
For some backwards compatibility, adjust #parameters and #source_location,
to show the parameters and source location of the method originally
defined. Also have the parameters and source location still be shown
by #inspect.
Clarify documentation of {Method,UnboundMethod}#owner.
Add tests based on the description of https://bugs.ruby-lang.org/issues/18435
and based on https://github.com/ruby/ruby/pull/5356#issuecomment-1005298809
Fixes [Bug #18435] [Bug #18729]
Co-authored-by: Benoit Daloze <eregontp@gmail.com>
Previously, newline: :lf was accepted but ignored. Where it
should have been used was commented out code that didn't work,
but unlike all other invalid values, using newline: :lf did
not raise an error.
This adds support for newline: :lf and :lf_newline, for consistency
with newline: :cr and :cr_newline. This is basically the same as
universal_newline, except that it only affects writing and not
reading due to RUBY_ECONV_NEWLINE_DECORATOR_WRITE_MASK.
Add tests for the File.open :newline option while here.
Fixes [Bug #12436]
* Optimize Marshal dump of large fixnum
Marshal's FIXNUM type only supports 31-bit fixnums, so on 64-bit
platforms the 63-bit fixnums need to be represented in Marshal's
BIGNUM.
Previously this was done by converting to a bugnum and serializing the
bignum object.
This commit avoids allocating the intermediate bignum object, instead
outputting the T_FIXNUM directly to a Marshal bignum. This maintains the
same representation as the previous implementation, including not using
LINKs for these large fixnums (an artifact of the previous
implementation always allocating a new BIGNUM).
This commit also avoids unnecessary st_lookups on immediate values,
which we know will not be in that table.
* Fastpath for loading FIXNUM from Marshal bignum
* Run update-deps
