| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
These macros have been defined here and there, so collect them.
|
|
|
|
|
|
|
|
|
|
|
|
Strings created from the C API with a len but no ptr have a buffer allocated
and the length set, but the buffer is not zero'd. This causes use of uninitialized
memory and allows reading memory that previously existed there.
For example, the rb_str_tmp_new spec fails when we create a string with
a large length greater than 24 bytes (since we zero the first 24 bytes
of the slot).
|
|
|
|
Set was moved to C only in Ruby 3.5, so it does not compile on Ruby 3.4
and earlier.
|
|
This should be a minimal C-API needed to deal with Set objects. It
supports creating the sets, checking whether an element is the set,
adding and removing elements, iterating over the elements, clearing
a set, and returning the size of the set.
Co-authored-by: Nobuyoshi Nakada <nobu.nakada@gmail.com>
|
|
rb_str_unlocktmp()
Notes:
Merged: https://github.com/ruby/ruby/pull/13615
|
|
Should fix a failure on the OpenBSD RubyCI machine.
Notes:
Merged: https://github.com/ruby/ruby/pull/13616
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13509
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13495
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13361
|
|
* The begp, lenp and stepp might not be written to, so they need default values.
Notes:
Merged: https://github.com/ruby/ruby/pull/13265
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13265
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13265
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13265
|
|
Ivars will longer be the only thing stored inline
via shapes, so keeping the `iv_index` and `ivptr` names
would be confusing.
Instance variables won't be the only thing stored inline
via shapes, so keeping the `ivptr` name would be confusing.
`field` encompass anything that can be stored in a VALUE array.
Similarly, `gen_ivtbl` becomes `gen_fields_tbl`.
Notes:
Merged: https://github.com/ruby/ruby/pull/13159
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/11975
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/11975
|
|
Originally, if a class was defined with the class keyword, the cref had a
const_added callback, and the superclass an inherited callback, const_added was
called first, and inherited second.
This was discussed in
https://bugs.ruby-lang.org/issues/21143
and an attempt at changing this order was made.
While both constant assignment and inheritance have happened before these
callbacks are invoked, it was deemed nice to have the same order as in
C = Class.new
This was mostly for alignment: In that last use case things happen at different
times and therefore the order of execution is kind of obvious, whereas when the
class keyword is involved, the order is opaque to the user and it is up to the
interpreter.
However, soon in
https://bugs.ruby-lang.org/issues/21193
Matz decided to play safe and keep the existing order.
This reverts commits:
de097fbe5f3df105bd2a26e72db06b0f5139bc1a
de48e47ddf78aba02fd9623bc7ce685540a10743
Notes:
Merged: https://github.com/ruby/ruby/pull/13085
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/13037
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12984
|
|
[Misc #21143]
[Bug #21193]
The previous change caused a backward compatibility issue with code
that called `Object.const_source_location` from the `inherited` callback.
To fix this, the order is now:
- Define the constant
- Invoke `inherited`
- Invoke `const_set`
Notes:
Merged: https://github.com/ruby/ruby/pull/12956
|
|
(Bug #21083)
https://bugs.ruby-lang.org/issues/21083
Notes:
Merged: https://github.com/ruby/ruby/pull/12622
|
|
[Misc #21143]
Conceptually this makes sense and is more consistent with using
the `Name = Class.new(Superclass)` alternative method.
However the new class is still named before `inherited` is called.
Notes:
Merged: https://github.com/ruby/ruby/pull/12927
|
|
Notes:
Merged-By: ioquatix <samuel@codeotaku.com>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12679
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12297
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12297
|
|
|
|
* YJIT: Replace Array#each only when YJIT is enabled
* Add comments about BUILTIN_ATTR_C_TRACE
* Make Ruby Array#each available with --yjit as well
* Fix all paths that expect a C location
* Use method_basic_definition_p to detect patches
* Copy a comment about C_TRACE flag to compilers
* Rephrase a comment about add_yjit_hook
* Give METHOD_ENTRY_BASIC flag to Array#each
* Add --yjit-c-builtin option
* Allow inconsistent source_location in test-spec
* Refactor a check of BUILTIN_ATTR_C_TRACE
* Set METHOD_ENTRY_BASIC without touching vm->running
Notes:
Merged-By: maximecb <maximecb@ruby-lang.org>
|
|
Notes:
Merged-By: ioquatix <samuel@codeotaku.com>
|
|
Notes:
Merged-By: ioquatix <samuel@codeotaku.com>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/10924
|
|
There is no guarantee that Integer#size will continue to return
`sizeof(long)` for small integers.
Use the `l!` specifier for Array#pack instead. It is a public
interface that has a direct relationship with the `long` type.
Notes:
Merged: https://github.com/ruby/ruby/pull/11130
|
|
What a "word" is when talking about sizes is confusing because it's a
highly overloaded term. Intel, Microsoft, and GDB are just a few vendors
that have their own definition of what a "word" is. Specs that used the
"wordsize" guard actually were mostly testing for the size of the C
`long` fundamental type, so rename the guard for clarity.
Also, get the size of `long` directly from RbConfig instead of guessing
using Integer#size. Integer#size is not guaranteed to have anything to
do with the `long` type.
Notes:
Merged: https://github.com/ruby/ruby/pull/11130
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Accecpt the same arguments as `caller` and `caller_locations`.
|
