Introduced `MRB_NO_METHOD_CACHE` which is inverse of `MRB_METHOD_CACHE`
that should be enabled intestinally. In addition, the default cache is
made bigger (128 -> 256).
- `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.
- The `s` specifier is a string pointer obtained without performing `mrb_str_modify()`, so it cannot be changed.
- The `z` specifier cannot be changed because it is a string pointer obtained by `RSTRING_CSTR()` which returns `const char *`.
* `_Static_assert` can also be used with `-std=gnu99` on GCC >= 4.6.
* `static_assert` can be used on MSVC.
* `static_assert` can be used even on old G++/Clang++ if
`__GXX_EXPERIMENTAL_CXX0X__` is defined.
`mrb_get_arg1()` raises `ArgumentError` if the method does not receive one
argument.
And replaces all `mrb_get_args(mrb, "o", &arg)` by the new function.
`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)`.
The difference between `mrb_singleton_class` and `mrb_singleton_class_ptr`:
- `mrb_singleton_class_ptr` returns `struct RClass*`.
- `mrb_singleton_class_ptr` returns `NULL` on immediate values where
`mrb_singleton_class` raises exceptions.
Keyword arguments can now be retrieved with the `:` specifier and
`mrb_kwargs` data.
For the interface, I referred to CRuby's `rb_get_kwargs()`.
For implementation, I referred to `OP_KARG` or etc.
`MRB_METHOD_TABLE_INLINE` was fragile. It requires `-falign-functions=n`.
On platform that uses higher bits of function pointers, you can use new
`MRB_METHOD_T_STRUCT` configuration macro.
This time, the allocated memory comes from the string object, which is
referenced from GC arena. The memory region will be reclaimed when the C
function called from VM is terminated, or the GC arena is restored.
When I found this function, I expected it to behave the same as the
`alloca(3)` function, but it is accually the `mrb_alloca()` function
does not free the heap until the `mrb_close()` function is called.
Also, even if it is deleted, it can be replaced with the combination
of the `MRB_TT_DATA` object and the `mrb_gv_set()` function if it is
sure necessary.
Yukihiro "Matz" Matsumoto