When there is a corresponding tag, the `RBreak` object is used to make a global jump.
Like CRuby, it can't be caught by `rescue`.
It is also the same as CRuby that it can be canceled in the middle by `ensure`.
### How to find the corresponding tag with `throw`
The called `catch` method remains in the call stack, and the tag also remains in the stack at that time.
So it is possible to find the called location by searching the two.
Note that no method can be given to the `proc` object specified in `RBreak`.
Therefore, inside the `catch` method, the argument block is called in a seemingly meaningless closure.
Also, as a countermeasure against `alias` etc., the `proc` object, which is the body of the `catch` method, is saved when mrbgem is initialized.
Because if the configuration file didn't contain any `conf.enable_test`, `rake test` would report an exception and exit.
```console
% cat my_config.rb
MRuby::Build.new { toolchain }
% rake MRUBY_CONFIG=my_config.rb test
...SNIP...
rake aborted!
NoMethodError: undefined method `invoke' for nil:NilClass
/var/tmp/mruby/tasks/test.rake:24:in `block (3 levels) in <top (required)>'
Tasks: TOP => test => test:build => test:build:lib
(See full trace by running task with --trace)
```
If the current directory is different from `MRUBY_ROOT` and it has` conf.build_dir` and `conf.enable_cxx_exception` set, it was generating a pathname outside of` build_dir`.
As a result, in some cases files unrelated to mruby could be linked.
```console
% pwd
/tmp/mruby/1/2/3/4/5/6
% mruby_dir=/tmp/mruby/a/b/c/d/mruby
% cat my_config.rb
MRuby::Build.new("host", "build/to/custom/directory") do
toolchain
enable_cxx_exception
end
% rake MRUBY_CONFIG=my_config.rb -f $mruby_dir/Rakefile > logs
% grep CXX logs
CXX a/b/c/d/mruby/src/error-cxx.cxx -> a/b/c/d/mruby/src/error-cxx.o
CXX a/b/c/d/mruby/src/gc-cxx.cxx -> a/b/c/d/mruby/src/gc-cxx.o
CXX a/b/c/d/mruby/src/vm-cxx.cxx -> a/b/c/d/mruby/src/vm-cxx.o
CXX a/b/c/d/mruby/mrbgems/mruby-compiler/core/codegen-cxx.cxx -> a/b/c/d/mruby/mrbgems/mruby-compiler/core/codegen-cxx.o
CXX a/b/c/d/mruby/mrbgems/mruby-compiler/core/y.tab-cxx.cxx -> a/b/c/d/mruby/mrbgems/mruby-compiler/core/y.tab-cxx.o
CXX ../a/b/c/d/mruby/src/error-cxx.cxx -> ../a/b/c/d/mruby/src/error-cxx.o
CXX ../a/b/c/d/mruby/src/gc-cxx.cxx -> ../a/b/c/d/mruby/src/gc-cxx.o
CXX ../a/b/c/d/mruby/src/vm-cxx.cxx -> ../a/b/c/d/mruby/src/vm-cxx.o
```
Prevents the auto-generated mrbc target source code from being compiled under host conditions.
This is because a build error occurred when `conf.enable_cxx_exception` was set.
* Use `_Complex` instead of `complex` (MSYS2 do not support `complex`)
* Use `_Dcomplex` instead of `_Complex` on MSCV
* Avoid operator division and multiplication of complex
### Example
```ruby
begin
throw 1
rescue Exception => e
puts e.message
end
```
#### Before this patch:
```console
$ bin/mruby example.rb
uncaught throw :1
```
#### After this patch (same as Ruby):
```console
$ bin/mruby example.rb
uncaught throw 1
```
This gem uses C99 `_Complex` features. You need a C compiler that
supports `_Complex` to enable this gem. All `gcc`, `clang`, `VC` support
`_Complex` so there should not be a big problem.
`.pi` files are created for `.o` files that `build.products` depends on, but
an error will occur if the build rule is unknown, so add a check.
I don't think this situation would normally arise. However, in
`mattn/mruby-onig-regexp`, when using bundled onigmo, onigmo's `.o` files
are added to dependency of `libmruby.a` in the second and subsequent builds,
and mruby does not know the build rule, so the following error had occured.
```console
rake aborted!
Don't know how to build task '/mruby/build/host/mrbgems/mruby-onig-regexp/onigmo-6.2.0/libonig_objs/ascii.pi' (See the list of available tasks with `rake --tasks`)
```
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.
The `init_SYMBOLS()` function implicitly defined in `MRB_PRESYM_DEFINE_VAR_AND_INITER()` requires some familiarity when trying to find it from the caller.
By introducing `MRB_PRESYM_INIT_SYMBOLS()`, it is possible to find directly from the identifier.
dearblue