Adds debug source information (line/file) when mrbc uses -g.
This commit results in usable backtraces for all gems when build_config
is setup with enable_debug.
- `mrb_num_div_int(mrb,x,y)` -> `mrb_div_int(mrb,x,y)`
- `mrb_num_div_flo(mrb,x,y)` -> `mrb_div_flo(x,y)`
They are internal function not supposed to be used outside of the core.
Previously, the following code would cause a `SIGSEGV`.
```ruby
mm = method(:throw)
define_method(:throw, ->(*args) { mm.call(*args) })
catch { |tag| throw tag }
```
I think the reason is in the `mrb_yield_with_class()` function:
- Even if a C function is called, `CI_ACC_SKIP` is used
- `cipop()` is not done if globally jumping from a C function
- define `MRB_TT_COMPLEX`
- change object structure (`struct RComplex`)
- add memory management for `MRB_TT_COMPLEX`
- avoid operator overloading as much as possible
- as a result, performance improved a log
- should work with and without `Rational` defined
- define `MRB_TT_RATIONAL`
- change object structure (`struct RRational`)
- add memory management for `MRB_TT_RATIONAL`
- avoid operator overloading as much as possible
- implement division overloading in C
- as a result, performance improved a lot
Since `mruby` does not have `Bignum`, `Float#divmod` could overflow, so
it will return `Float` values when the divided value does not fit in
`mrb_int`. This behavior will be changed when `Bignum` is introduced to
`mruby` in the future.
#### Before this patch:
```console
$ bin/mruby -e 'p(Float::NAN/0)'
Infinity
```
#### After this patch (same as Ruby):
```console
$ bin/mruby -e 'p(Float::NAN/0)'
NaN
```
It used to be return the default value if available, but it should
ignore the default value for behavior consistency. CRuby will adopt
this behavior too in the future. [ruby-bugs:16908]
Add new pool value type `IREP_TT_BIGINT` and generate integer overflow
error in the VM. In the future, `mruby` will support `Bignum` for
integers bigger than `mrb_int` (probably using `mpz`).
- Added to `mruby-binding-core`
- `Binding#local_variable_defined?`
- `Binding#local_variable_get`
- `Binding#local_variable_set`
- `Binding#local_variables`
- `Binding#receiver`
- `Binding#source_location`
- `Binding#inspect`
- Added to `mruby-proc-binding`
- `Proc#binding`
The reason for separating `Proc#binding` is that core-mrbgems has a method that returns a closure object to minimize possible problems with being able to manipulate internal variables.
By separating it as different mrbgem, each user can judge this problem and incorporate it arbitrarily.
In `h_check_modified()`, in the case of `MRB_NO_BOXING`, `ht_ea()` or
`ht_ea_capa()` for AR may read uninitialized area. Therefore, do not use
those macros for AR in `MRB_NO_BOXING` (but in the case of `MRB_64BIT`,
`ht_ea_capa()` is the same as `ar_ea_capa()`, so use it).
fix#5332
### Example
##### example.rb
```ruby
h = {}
(1..17).each{h[_1] = _1}
(1..16).each{h.delete(_1)}
h.rehash
```
##### ASAN report
```console
$ bin/mruby example.rb
==52587==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000006998 at pc 0x55a29cddf96b bp 0x7fff7b1b1720 sp 0x7fff7b1b1710
READ of size 4 at 0x602000006998 thread T0
#0 0x55a29cddf96a in ib_it_next /mruby/src/hash.c:639
#1 0x55a29cde2ca2 in ht_rehash /mruby/src/hash.c:900
#2 0x55a29cde379f in h_rehash /mruby/src/hash.c:996
#3 0x55a29cde7f3d in mrb_hash_rehash /mruby/src/hash.c:1735
#4 0x55a29ce77b62 in mrb_vm_exec /mruby/src/vm.c:1451
#5 0x55a29ce5fa88 in mrb_vm_run /mruby/src/vm.c:981
#6 0x55a29ceb87e1 in mrb_top_run /mruby/src/vm.c:2874
#7 0x55a29cf36bdf in mrb_load_exec mrbgems/mruby-compiler/core/parse.y:6805
#8 0x55a29cf36f25 in mrb_load_detect_file_cxt mrbgems/mruby-compiler/core/parse.y:6848
#9 0x55a29cdba0a2 in main /mruby/mrbgems/mruby-bin-mruby/tools/mruby/mruby.c:347
#10 0x7f24ef43b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#11 0x55a29cdb4a6d in _start (/mruby/bin/mruby+0x2a3a6d)
0x602000006998 is located 0 bytes to the right of 8-byte region [0x602000006990,0x602000006998)
allocated by thread T0 here:
#0 0x7f24f01cfffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
#1 0x55a29ceb9440 in mrb_default_allocf /mruby/src/state.c:68
#2 0x55a29cdba747 in mrb_realloc_simple /mruby/src/gc.c:228
#3 0x55a29cdba928 in mrb_realloc /mruby/src/gc.c:242
#4 0x55a29cde12e5 in ht_init /mruby/src/hash.c:749
#5 0x55a29cde2b8e in ht_rehash /mruby/src/hash.c:897
#6 0x55a29cde379f in h_rehash /mruby/src/hash.c:996
#7 0x55a29cde7f3d in mrb_hash_rehash /mruby/src/hash.c:1735
#8 0x55a29ce77b62 in mrb_vm_exec /mruby/src/vm.c:1451
#9 0x55a29ce5fa88 in mrb_vm_run /mruby/src/vm.c:981
#10 0x55a29ceb87e1 in mrb_top_run /mruby/src/vm.c:2874
#11 0x55a29cf36bdf in mrb_load_exec mrbgems/mruby-compiler/core/parse.y:6805
#12 0x55a29cf36f25 in mrb_load_detect_file_cxt mrbgems/mruby-compiler/core/parse.y:6848
#13 0x55a29cdba0a2 in main /mruby/mrbgems/mruby-bin-mruby/tools/mruby/mruby.c:347
#14 0x7f24ef43b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
```
We have introduced following new instructions.
* `OP_LAMBDA16`
* `OP_BLOCK16`
* `OP_METHOD16`
* `OP_EXEC16`
Each instruction uses 16 bits operand for `reps` index. Since new
instructions are added, `mruby/c` VM should be updated.
Due to new instructions, dump format compatibility is lost, we have
increased `RITE_BINARY_MAJOR_VER`.
In addition, we have decreased the size of `refcnt` in `mrb_irep` from
`uint32_t` to `uint16_t`, which is reasonably big enough.
Yukihiro "Matz" Matsumoto