OP_LOADI stores an 8 bit integer to a register, so we renamed the
instruction name to describe the behavior more precisely, like
OP_LOADI16 and OP_LOADI32.
Recent changes make mrb_irep_remove_lv() used no longer. Removing this
function would not make any compatibility issue, since it's an internal
function.
To avoid confusion with pools in irep, we renamed region-based memory
manager from pool to mempool.
- rename pool.c to mempool.c
- separate mempool.h
- rename all mrb_pool to mrb_mempool
So if someone is using pool.c functions (I suppose no one does though),
they need to rename all `mrb_pool` to `mrb_mempool` and include
`mruby/mempool.h` header at the top.
mrb_pool_value is a structure that represents a value in the irep
literal pool and is unrelated to mrb_pool, which performs region-based
memory management. It has been renamed mrb_irep_pool to avoid confusion.
However, on C, there is no easy way to pass keyword arguments.
Therefore, when called `Kernel#instance_exec` on C, keyword arguments are converted to positional arguments.
This is a limitation of current mruby.
fixed#6389
As #6359 pointed out, calling const_missing hook from E_XXX_ERROR (that
calls mrb_exc_get_id()) can be an attack vector. Since E_XXX_ERROR is
supposed to be a defined error class, we think that the situation where
it is undefined and the const_missing hook is called should be detected
as an error; fix#6359
This reverts commit e76bebe836 (#6309).
Because it crashes limited to gcc13 -O3.
ref. #6358.
Also, benchmark tests have shown that revert tends to be preferable in this time.
Suppress warnings for 0-length sequences is not required.
By commit f1a02dff58, it was introduced.
By commit 24939723d7, pseudo-variable length arrays are now used and the warning suppression is no longer needed.
By commit e8841fbf58, moved the intervening code.
Static proc objects defined as methods may be placed in 4-byte alignments in 32-bit environments.
This may be misinterpreted as an immediate value depending on the address.
Since C11 and C++11 have additional language features for byte alignment, corresponding compilers use them to define the `mrb_alignas()` macro.
For earlier compilers, they use their own extensions to define the `mrb_alignas()` macro.
GCC supports `__attribute__((aligned(alignment)))` since at least version 2.95.3 (1999).
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#IDX305
According to GPT-4, support was added in version 2.7 (1995).
It is not known which version of Visual C++ added support for `__declspec(align(n))`.
According to GPT-4, at least Visual C++ 6.0 (1998) seems to support it.
Also, the documentation of past Intel C/C++ compilers that support `__declspec(align(n))` makes reference to support with Visual C++ 4.2 (1996).
https://www.intel.com/content/dam/www/public/ijkk/jp/ja/documents/developer/ccomp40j.pdf
This reverts commit ad2e626e7a.
Because of the changes made by #6282, the following code caused a problem.
```ruby
b = proc { break "BAD!" }
p self.tap { b.call }
# (expected) => break from proc-closure (LocalJumpError)
# (after #6282) => "BAD!"
```
I revived the `mrb_callinfo::blk` field to fix this, but it did not overcome the following problem.
```ruby
def m(&b); b = b.clone; GC.start; b.call; end
p m { break "OK!" }
# (expected) => "OK!"
# (revived blk) => break from proc-closure (LocalJumpError)
```
mimaki