Previously this would copy the symlink root as a symlink instead
of creating a new root directory. This modifies the source
to expand it using File.realpath before starting the copy.
Fixes Ruby Bug 12123
https://github.com/ruby/fileutils/commit/7359cef359
Previously this would give an error such as:
TestFileUtils#test_cp_r_dev [c:/fileutils/test/fileutils/test_fileutils.rb:455]:
[RuntimeError] exception expected, not.
Class: <TypeError>
Message: <"no implicit conversion of nil into String">
https://github.com/ruby/fileutils/commit/0ce0fefbeb
If FileUtils is included into another object, and verbose mode is
used, a FrozenError is currently raised unless the object has the
@fileutils_output and @fileutils_label instance variables.
This fixes things so that it does not attempt to set the instance
variables, but it still uses them if they are present.
https://github.com/ruby/fileutils/commit/689cb9c56a
Previously, this was broken. Trying to copy a FIFO would raise a
NoMethodError if File.mkfifo was defined. Trying to copy a UNIX
socket would raise a RuntimeError as File.mknod is not something
Ruby defines.
Handle the FIFO issue using File.mkfifo instead of mkfifo.
Handle the UNIX Socket issue by creating a unix socket.
Continue to not support character or block devices, raising a
RuntimeError for both.
Add tests for FIFO, UNIX Socket, and character/block devices.
https://github.com/ruby/fileutils/commit/123903532d
This fixes instance_exec and similar methods. It also fixes
Enumerator::Yielder#yield, rb_yield_block, and a couple of cases
with Proc#{<<,>>}.
This support requires the addition of rb_yield_values_kw, similar to
rb_yield_values2, for passing the keyword flag.
Unlike earlier attempts at this, this does not modify the rb_block_call_func
type or add a separate function type. The functions of type
rb_block_call_func are called by Ruby with a separate VM frame, and we can
get the keyword flag information from the VM frame flags, so it doesn't need
to be passed as a function argument.
These changes require the following VM functions accept a keyword flag:
* vm_yield_with_cref
* vm_yield
* vm_yield_with_block
I've been compiling with:
```
set -lx cflags '-std=c99 -Werror=pedantic -pedantic-errors'
```
But compilation would fail with the following:
```
cont.c:296:90: error: format specifies type 'void *' but the argument has type 'struct fiber_pool_stack *' [-Werror,-Wformat-pedantic]
if (DEBUG) fprintf(stderr, "fiber_pool_stack_alloca(%p): %"PRIuSIZE"/%"PRIuSIZE"\n", stack, offset, stack->available);
~~ ^~~~~
cont.c:467:24: error: format specifies type 'void *' but the argument has type 'struct fiber_pool *' [-Werror,-Wformat-pedantic]
count, fiber_pool, fiber_pool->used, fiber_pool->count, size, fiber_pool->vm_stack_size);
^~~~~~~~~~
cont.c:588:83: error: format specifies type 'void *' but the argument has type 'struct fiber_pool_vacancy *' [-Werror,-Wformat-pedantic]
if (DEBUG) fprintf(stderr, "fiber_pool_stack_acquire: %p used=%"PRIuSIZE"\n", fiber_pool->vacancies, fiber_pool->used);
~~ ^~~~~~~~~~~~~~~~~~~~~
cont.c:736:76: error: format specifies type 'void *' but the argument has type 'rb_fiber_t *' (aka 'struct rb_fiber_struct *')
[-Werror,-Wformat-pedantic]
if (DEBUG) fprintf(stderr, "fiber_stack_release: %p, stack.base=%p\n", fiber, fiber->stack.base);
```
This commit just fixes the pedantic errors
`freeze_string` essentially called iseq_add_mark_object_compile_time. I
need to know where all writes occur on the `rb_iseq_t`, so this commit
separates the function calls so we can add write barriers in the right
place.
Move the "add mark object" function to the location where we should be
calling RB_OBJ_WRITTEN. I'm going to add verification code next so we
can make sure the objects we're adding to the array are also reachable
from the mark function.
* got rid of inadvertent label lists.
* marked up resolve_feature_path method names.
* fixed indentation of UnboundMethod#bind_call and marked up as
RDoc.
It's unlikely anyone would actually hit these. The methods are
private, you only hit this code path if calling these methods
before performing the SSL connection, and there is already a
verbose warning issued.
