- It can now deal with operands in the range of `OP_EXT*`.
- It can now call the same method as the variable name without arguments.
```ruby
def a
"Safe!"
end
a = "Auto!"
eval "a()" # call method `a`
```
It was making a negative integer if the highest-order bit of a 16-bit
integer was 1.
no patched:
```ruby
p 0x7fff # => 32767
p 0x8000 # => -32768
p 0xffff # => -1
p 0x10000 # => 65536
```
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.
The basic idea of this change is from @dearblue.
Note: the arguments of `mrb_str_pool()` have changed, but the function
is provided for internal use (No `MRB_API`). So basically you don't have
to worry about the change.
Besides that fix bugs that mistakenly calls `raise_error` that emits
code to raise runtime error instead of `codegen_error` that terminates
code generation immediately.
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.
The addresses for packed inline symbols reference `mrb->symbuf` that
could be overridden by the later call of `mrb_sym2name_len`. Since
file names in call stack information are kept as symbols, keeping the
address in the C structures could cause problems like #4342.
This changes small incompatible changes in function prototypes:
* `mrb_parser_get_filename`: return value changed to `mrb_sym`.
* `mrb_debug_get_filename`: add `mrb_state*` as a first argument.
* `mrb_debug_get_line`: ditto.
I believe above functions are almost internal, and no third-party
mrbgem use them.
e.g.
```
def m(a,(b,c),d); p [a,b,c,d]; end
m(1,[2,3],4) # => [1,2,3,4]
```
mruby limitation:
Destructured arguments (`b` and `c` in above example) cannot be accessed
from the default expression of optional arguments and keyword arguments,
since actual assignment is done after the evaluation of those default
expressions. Thus:
```
def f(a,(b,c),d=b)
p [a,b,c,d]
end
f(1,[2,3])
```
raises `NoMethodError` for `b` in mruby.
Yukihiro "Matz" Matsumoto