After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_rescue / rb_rescue2, which revealed many arity / type mismatches.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. Let's start from making
rb_block_call_func_t strict, and apply RB_BLOCK_CALL_FUNC_ARGLIST liberally.
For array.c (Array#sort) and enum.c (Enumerable#sort_by),
add comments mentioning that sort.reverse! / sort_by { ... }.reverse!
can/should be used to reverse the result. [ci skip]
Existing doc for Enumerable#include? and member? has some problems.
* `IO.constants` is not commonly used, and only some know
that `SEEK_SET` is actually included in constants.
* `IO.constants` is actually an Array, not the example is not
appropriate for `Enumerable` module.
So in this commit, the old example is replaced with new one.
New example uses integer range, which is much simpler and easier to
understand.
Closes: https://github.com/ruby/ruby/pull/2168
memo.float_value might change inside of hash_sum. In case it
flipped from false to true there, and the calculated sum is Inf,
memo.c might not be initialized at all. This is bad.
Found using memory sanitizer:
==55293==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x55dfb8d6c529 in rb_float_new_inline internal.h:1814:53
#1 0x55dfb8d1b30c in enum_sum enum.c:4017:18
#2 0x55dfb86d75ad in call_cfunc_m1 vm_insnhelper.c:2041:12
#3 0x55dfb864b141 in vm_call_cfunc_with_frame vm_insnhelper.c:2207:11
#4 0x55dfb85e843d in vm_call_cfunc vm_insnhelper.c:2225:12
#5 0x55dfb85e08f3 in vm_call_method_each_type vm_insnhelper.c:2560:9
#6 0x55dfb85de9c7 in vm_call_method vm_insnhelper.c:2686:13
#7 0x55dfb849eac6 in vm_call_general vm_insnhelper.c:2730:12
#8 0x55dfb8686103 in vm_sendish vm_insnhelper.c:3623:11
#9 0x55dfb84dc29e in vm_exec_core insns.def:789:11
* enum.c (enum_tally): new methods Enumerable#tally, which group
and count elements of the collection. [Feature #11076]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67020 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Especially over checking argc then calling rb_scan_args just to
raise an ArgumentError.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66238 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* include/ruby/ruby.h: de-transient at
`RARRAY_PTR_USE` and `RARRAY_PTR_USE_START`.
Introduce `RARRAY_PTR_USE_TRANSIENT` and
`RARRAY_PTR_USE_START_TRANSIENT` if you don't want to
de-transient an array. Generally, it is difficult
so C-extension writers should not use them.
* array.c: use `RARRAY_PTR_USE_TRANSIENT` if possible.
* hash.c: ditto.
* enum.c (enum_sort_by): remove `rb_ary_transient_heap_evacuate()`
because `RARRAY_PTR_USE` do de-transient.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66165 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* transient_heap.c, transient_heap.h: implement TransientHeap (theap).
theap is designed for Ruby's object system. theap is like Eden heap
on generational GC terminology. theap allocation is very fast because
it only needs to bump up pointer and deallocation is also fast because
we don't do anything. However we need to evacuate (Copy GC terminology)
if theap memory is long-lived. Evacuation logic is needed for each type.
See [Bug #14858] for details.
* array.c: Now, theap for T_ARRAY is supported.
ary_heap_alloc() tries to allocate memory area from theap. If this trial
sccesses, this array has theap ptr and RARRAY_TRANSIENT_FLAG is turned on.
We don't need to free theap ptr.
* ruby.h: RARRAY_CONST_PTR() returns malloc'ed memory area. It menas that
if ary is allocated at theap, force evacuation to malloc'ed memory.
It makes programs slow, but very compatible with current code because
theap memory can be evacuated (theap memory will be recycled).
If you want to get transient heap ptr, use RARRAY_CONST_PTR_TRANSIENT()
instead of RARRAY_CONST_PTR(). If you can't understand when evacuation
will occur, use RARRAY_CONST_PTR().
(re-commit of r65444)
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65449 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* transient_heap.c, transient_heap.h: implement TransientHeap (theap).
theap is designed for Ruby's object system. theap is like Eden heap
on generational GC terminology. theap allocation is very fast because
it only needs to bump up pointer and deallocation is also fast because
we don't do anything. However we need to evacuate (Copy GC terminology)
if theap memory is long-lived. Evacuation logic is needed for each type.
See [Bug #14858] for details.
* array.c: Now, theap for T_ARRAY is supported.
ary_heap_alloc() tries to allocate memory area from theap. If this trial
sccesses, this array has theap ptr and RARRAY_TRANSIENT_FLAG is turned on.
We don't need to free theap ptr.
* ruby.h: RARRAY_CONST_PTR() returns malloc'ed memory area. It menas that
if ary is allocated at theap, force evacuation to malloc'ed memory.
It makes programs slow, but very compatible with current code because
theap memory can be evacuated (theap memory will be recycled).
If you want to get transient heap ptr, use RARRAY_CONST_PTR_TRANSIENT()
instead of RARRAY_CONST_PTR(). If you can't understand when evacuation
will occur, use RARRAY_CONST_PTR().
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65444 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* class.c (rb_keyword_error_new): use RARRAY_AREF() because
RARRAY_CONST_PTR() can introduce additional overhead in a futre.
Same fixes for other files.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65430 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* array.c (yield_indexed_values): use RARRAY_AREF/ASET instead of
using RARRAY_PTR().
* enum.c (nmin_filter): ditto.
* proc.c (rb_sym_to_proc): ditto.
* enum.c (rb_nmin_run): use RARRAY_PTR_USE() instead of RARRAY_PTR().
It is safe because they don't make new referecen from an array.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64986 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* include/ruby/ruby.h (UNREACHABLE_RETURN): UNREACHABLE at the end
of non-void functions.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64025 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* enum.c (imemo_count_up, imemo_count_value): promote the counter
value to a bignum on overflow. [Bug #14805]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63554 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* In Enumerable, Enumerator::Lazy, Array, Hash and Set
[Feature #13784] [ruby-core:82285]
* Share specs for the various #select#select! methods and
reuse them for #filter/#filter!.
* Add corresponding filter tests for select tests.
* Update NEWS.
[Fix GH-1824]
From: Alexander Patrick <adp90@case.edu>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62575 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This will fix the formatting shown on detect|find and revese_arch
generated by RDoc.
[Fix GH-1816]
From: Espartaco Palma <esparta@gmail.com>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62397 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It seems HUGE_VAL is already used. Why not eliminate INTINITY.
NAN is also float. That of double is called nan(). This is also
fixed.
Signed-off-by: Urabe, Shyouhei <shyouhei@ruby-lang.org>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61938 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* enum.c: [DOC] reword docs for Enumerable#{any?,all?,none?,one?}
to not mention the receiver (`enum') from call-seq, because it
does not appear in the call-seq of the rendered HTML docs.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61229 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
and specialized Array#any? and Hash#any?
Based on patch by D.E. Akers [#11286]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61098 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* enum.c (enum_cycle_size): check an argument before the size of
the receiver, if it is given.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60668 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
卜部昌平
Jeremy Evans
OKURA Masafumi
Yusuke Endoh
Nobuyoshi Nakada
Kazuhiro NISHIYAMA
Martin Dürst
Alfonso Jiménez
Marcus Stollsteimer
nagachika
nobu
svn
ko1
kazu
naruse
eregon
shyouhei
stomar
marcandre