It is now possible to specify return destination directly.
This allows callinfo to distinguish between calls to the same proc object.
At the same time, the `Kernel#catch` method is adjusted.
By removing the previously required double lambda object, the REnv object is no longer created as well.
Since it is confusing that the term `mrbc` stands for both "mruby
compiler" and "mruby compiler context" in the source code. Instead,
we use `mrb_ccontext` (stands for compiler context) prefix hereafter.
We choose `mrb_ccontext` because we have already used `mrb_context` (for
VM execusion context).
Since `Env` objects are shared by Blocks/Procs in the same context,
making multiple aliases in one context screws up with alias names.
New implementation uses alias bodies (Procs) to refer new names.
As a side effect, `__callee__` stop working correctly for aliases.
To fix this `__callee__` problem, we need to keep alias method names in
`callinfo`, which consumes more memory. We are wondering that is worth
the compatibility.
The function requires the buffer bigger than `mrb_packed_int_len()`
anyway, so we don't need boundary checks for each iteration. Should
makes the function a little bit faster.
Like previous recursive `<=>` check, scan call stack to detect recursive
`inspect` calls. We no longer need incomplete `_inspect` hack to pass
around a hash table to record objects currently inspecting.
The correct technique now is "Token Threading".
However, the new name was chosen because it was felt that if a different technique was added in the future, there would be no need to replace it.
Passing a proc generated by the following method to `mrb_yield()` or `mrb_yield_argv()` no longer causes `SIGSEGV`:
- C functions made into proc objects with `mrb_proc_new_cfunc()`.
- A proc object which is the top level of a program generated by `mrb_load_string_cxt()` etc. with `mrbc_context::no_exec` enabled.
See also: #5932
The `REnv` object is difficult to deal with, and it would be ideal if the user did not have to manipulate it directly.
In some previous situations, it was necessary to call `mrb_env_unshare()`, a non-API function, after `mrb_load_string()` or similar.
With this patch, it is no longer necessary for users to use `mrb_env_unshare()` directly, as it is now handled internally simply by using the `mrb_vm_ci_env_clear()` function.
Also, `mrb_vm_ci_env_set()` is demoted from the `MRB_API` function for the same reason.
ref. commit 1ab3da6f08
dearblue