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.
It used heap allocated memory for the parser stack, but there's
possibility of parser termination by exceptions. In that case, the
parser stack memory is leaked.
We were afraid of stack consumption, but parser stack size is only 4KB,
so we don't have to worry about it (at least for the parser).
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.
Instead of `irep` links, we added a `upper` link to `struct RProc`.
To make a space for the `upper` link, we moved `target_class` reference.
If a `Proc` does not have `env`, `target_class` is saved in an `union`
shared with `env` (if a `Proc` has env, you can tell it by `MRB_PROC_ENV_P()).
Otherwise `target_class` is referenced from `env->c`. We removed links
in `env` as well.
This change removes 2 members from `mrb_irep` struct, thus saving 2
words per method/proc/block. This also fixes potential memory leaks
due to the circular references caused by a link from `mrb_irep`.
KOBAYASHI Shuji