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.
Some functions called by `mrb_vm_exec()` involve re-entry into the mruby VM.
If the `ci` variable is not updated after re-entry, use-after-free is caused.
This patch makes the following after-call fixes.
| called | might call methods
| ----------------------- | ----------------
| `mrb_ary_splat()` | `#to_a`
| `hash_new_from_regs()` | `#eql?` `#hash`
| `mrb_hash_delete_key()` | `#eql?` `#hash`
| `mrb_hash_get()` | `#eql?` `#hash` `#default`
| `mrb_hash_key_p()` | `#eql?` `#hash`
| `mrb_hash_merge()` | `#eql?` `#hash`
| `mrb_hash_set()` | `#eql?` `#hash`
| `mrb_range_new()` | `#<=>`
When multiple identical proc objects are placed on the call stack, it is not possible to distinguish where to `return`.
Therefore, use env object comparisons to do this.
fixed#6411
C to Ruby calls using `mrb_exec_irep()` were not forwarding arguments.
There was also a problem in setting the target class and method ID, which is also fixed.
This issue was discovered during the work to fix#6389.
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
The callinfo refers blk since #5786 but not marked at the time. Later we
added reclamation check by #5791 but its repeated heap scans decrease
the performance drastically in some cases. So the original @dearblue's
solution should be taken
Probably we need to always keep the original block at the bottom of
arguments. And the explicit block argument should be a normal local
variable. We will investigate it later.
The following assertions can be added to omit the `if` block
- env object must be non-null
- env object must be in a shared state with the stack
The current caller is believed to satisfy the condition.
- Can refer directly to `proc->e.env` after `MRB_PROC_ENV_P()`.
- Can omit `MRB_ENV_ONSTACK_P()` since `mrb->c` is never NULL and can be directly compared to `env->cxt`.
- Can avoid `goto` by putting the code block that raises the `LocalJumpError` at the end.
Clearing errors at the beginning of `mrb_vm_exec()` essentially keeps the mruby VM in a non-error state.
For consistency, functions such as `mrb_funcall()` check for errors when control returns from a C function as a method.
In the case of a tail call, it should return to `mrb_vm_exec()` afterwards, so error checking is performed there.
Instructions issued while `mrb->exc` is non-null should be limited to `OP_EXCEPT`, the jump target of the catch handler table.
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)
```
- There was some unnecessary complexity in `OP_BREAK` introduced in commit ad2e626 (#6282).
- Since `mrb->c` is never NULL, there is no need to check it with `MRB_ENV_ONSTACK_P()` beforehand.
Yukihiro "Matz" Matsumoto