It seems to be preferable to be able to handle pointers of type `char` as well.
For this purpose, `mrb_nanbox_tt_inline` has been reorganized.
- `MRB_NANBOX_TT_POINTER` has been split into `MRB_NANBOX_TT_OBJECT` and `MRB_NANBOX_TT_CPTR`
- `MRB_NANBOX_TT_SYMBOL` has been merged into `MRB_NANBOX_TT_MISC`
The main purpose is to increase the chances of finding presym and to prevent errors due to C++11 lambda expressions.
- The argument to receive the class may be written, for example, `mrb_class_get()`.
- The argument that receives the implementation function of the method may be a C++ lambda expression.
In this case, if multiple variable declarations are separated by colons, the preprocessor will recognize them as argument delimiters and report an error.
This patch prevents it from happening.
```c++
// When preprocessing...
func([] { int x, y, z; })
// ^^^^^^^^^^ 1st argument?
// ^ 2nd argument?
// ^^^^ 3rd argument?
```
ref. commit 7f40b645d2
Currently, the build configurations `MRB_USE_COMPLEX` and `MRB_USE_RATIONAL` are not listed in the documentation.
In other words, they are hidden settings.
They are defined in `mrbgems/mruby-{complex,rational}/mrbgem.rake`.
So this patch assumes that it is safe to refer to these functions in core-gems directly from core functions.
However, applications that link with `libmruby_core.a` will have compatibility issues.
In fact, `mrbgems/mruby-bin-mrbc` links with `libmruby_core.a`, so I had to prepare a dummy function.
The main reason for failure is to exceed the time limit, and even when it succeeds, there is less than a minute left.
The 10-minute time limit seems to be too short.
ref. #5613.
I mentioned in #5540 that there was no reentrant to the virtual machine, but in fact it was still a possibility at that point.
Also, the variable `ci` needs to be recalculated at the same time.
ref. #5613
I checked with Valgrind, and the methods that can cause use-after-free are `Array#rotate`, `Array#rotate!`, and `String#byteslice`.
Since `String#rindex` uses `RSTRING_LEN()` indirectly inside the function, no reference to the out-of-bounds range is generated.
Since `mrb_to_integer` and `mrb_to_float` does not convert the object
but checks types, they are named so by historical reason. We introduced
properly named functions.
This commit obsoletes the following functions:
* mrb_to_integer()
* mrb_to_int()
* mrb_to_float()
Use `mrb_ensure_int_type()` instead for the first 2 functions. Use
`mrb_ensure_float_type()` for the last.
mimaki