- `mrb_convert_type`
- `mrb_check_convert_type`
Those function no longer take `tname` string representation of desired
type, and take method symbols instead of `const char*` names. This is
incompatible change. I hope no third-party gems use those functions.
Formerly, `__send__(*args)` modified `args` with `Array#shift`.
This bug affects optcarrot.
This changeset avoids the array destruction by using
`args = args[1, len-1]`.
Which loads 16bit integer to the register. The instruction number should
be reorder on massive instruction refactoring. The instruction is added
for `mruby/c` which had performance issue with `OP_EXT`. With this
instruction, `mruby/c` VM can just raise errors on `OP_EXT` extension
instructions.
`mrb_run` requires to push callinfo stack before calling, which is very
hard from outside of `vm.c`. So there should be virtually no correct
usage of the function, hence the cause of #4488. We removed it.
You can use `mrb_top_run(mrb, proc, self, 0)` instead of
`mrb_run(mrb, proc self)`.
If `mrb->jmp` is `NULL` and the function `mrb_funcall_with_block()` is
called, GC Arena is returned from the function with over-used.
- A normal (no global exodus) return will consume two GC Arena's.
- In the event of an exception, five GC Arena are consumed.
This patch reduces consumption in both cases to one.
We needed to preserve the original method name somewhere. We kept it in
the `env` structure pointed from aliased methods. #1457 and #1531 tried
to address this issue. But this patch is more memory efficient.
Limitation: this fix does not support `super` from methods defined by
`define_method`. This limitation may be addressed in the future, but
it's low priority.
But this changes requires `OP_ARYCAT` and `OP_ARYPUSH` to accept `nil`
as their first operand. Alternative VMs (e.g. `mruby/c`) that understand
mruby bytecode need to be updated.
The binary sizes (gems are only `mruby-bin-mruby`) are reduced slightly in
my environment than before the introduction of new specifiers/modifiers
(5116789a) with this change.
------------+-------------------+-------------------+--------
BINARY | BEFORE (5116789a) | AFTER (This PR) | RATIO
------------+-------------------+-------------------+--------
mruby | 593416 bytes | 593208 bytes | -0.04%
libmruby.a | 769048 bytes | 767264 bytes | -0.23%
------------+-------------------+-------------------+--------
BTW, I accidentally changed `tasks/toolchains/visualcpp.rake` at #4613,
so I put it back.
Example:
$ bin/mruby -e '(Float::INFINITY - Float::INFINITY).nan?'
zsh: segmentation fault
Cause:
`SET_FLOAT_VALUE` is not used. It is needed for normalizing NaN.
Treatment:
In my environment, this issue could be reproduced only when
`infinity - infinity`, however `SET_FLOAT_VALUE` should be used in all
arithmetic operations (regardless of boxing setting), I think.
So I fixed all similar codes by extracting to macro.
Functions to add prototypes to headers:
* mrb_ary_splice()
* mrb_notimplement()
* mrb_vformat()
* mrb_cstr_to_dbl()
* mrb_cstr_to_inum()
Functions to be made `static` (`MRB_API` was not needed):
* mrb_mod_module_function()
* mrb_obj_hash()
* mrb_str_len_to_inum()
Functions to remove `MRB_API` from definitions (referenced from within `libmruby`):
* mrb_mod_cv_defined()
* mrb_mod_cv_get()
* mrb_f_send()
The saving `pc` position should be beginning of the instruction.
But after `mruby 2.0` byte code modification, the `pc` variable
points the beginning of the next instruction. We save the previous
position in a local variable `pc0`.
Yukihiro "Matz" Matsumoto