The method introduced by #5979 causes a fault by swapping classes.
```console
% bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
zsh: segmentation fault (core dumped) bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
```
After applying this patch, a `TypeError` exception will be raised.
```console
% bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
trace (most recent call last):
[1] -e:1
-e:1:in method: allocation failure of Proc (TypeError)
```
However, if the `mrb_vtype` is the same object, the same care must still be taken as before.
```console
% bin/mruby -e 'Method = Binding; p method(:puts).eval("12345")'
trace (most recent call last):
[1] -e:1
-e:1:in eval: wrong argument type nil (expected Proc) (TypeError)
```
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 `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.
Since when env objects reference the context, we no longer need to
unshare (stack reallocate) env objects. Currently all env objects
referenced from fibers are already recycled, so we removed unnecessary
code altogether.
Calling `Class#allocate` with `UnboundMethod#bind_call` usually succeeds without problems.
If this behavior does not make us happy, we can now prohibit it with `MRB_SET_INSTANCE_TT(klass, MRB_TT_UNDEF)`.
At the same time, it applies to the `Binding`, `Complex`, `Data`, `Float`, `Integer`, `Method`, `Rational` and `UnboundMethod` classes.
If pre-allocate object is modified (e.g. singleton class added) in
certain timing, some objects may be swept even if it's alive.
The problem was reported by Denis Kasak via private communication.
Some error objects are referenced from `mrb_state`, and previously they
are simply marked as root objects. But when they are not referenced from
other part of the program, they are no longer used at the current incarnation.
That means we can safely reclaim their child objects (their messages and
backtrace information).
dearblue