The `REnv` object is difficult to deal with, and it would be ideal if the user did not have to manipulate it directly.
In some previous situations, it was necessary to call `mrb_env_unshare()`, a non-API function, after `mrb_load_string()` or similar.
With this patch, it is no longer necessary for users to use `mrb_env_unshare()` directly, as it is now handled internally simply by using the `mrb_vm_ci_env_clear()` function.
Also, `mrb_vm_ci_env_set()` is demoted from the `MRB_API` function for the same reason.
ref. commit 1ab3da6f08
Since `bin/mruby-config` now points to a directory relative to itself, it is no longer possible to reach `include/` or `lib/`.
Therefore, avoid placing entities in them.
This is so that the build directory can be regarded as a temporary installation directory to work in.
Directories set in `MRuby::Gem::Specification#export_include_paths` are used as they are if they are subdirectories placed under `gem.dir`.
Files are placed under `<build-dir>/include/mruby/gems/<gem-name>/<gem-include_paths>` to separate each GEM.
When GEM is compiled by building `libmruby.a`, the same `include_paths` will be set as before, so it is expected that no unintended references will be made.
This was how clone command was previously being generated, for example:
```
git clone --recursive --branch "master" --depth 1 https://github.com/mattn/mruby-onig-regexp.git /path/to mruby with spaces/mruby-3.1.0/build/repos/wasm/mruby-onig-regexp
```
Now it's changed so the path is quoted and will work when containing
spaces:
```
git clone --recursive --branch "master" --depth 1 https://github.com/mattn/mruby-onig-regexp.git "/path/to mruby with spaces/mruby-3.1.0/build/repos/wasm/mruby-onig-regexp"
```
Similar for the other commands.
Allow to update `doc/internal/opcode.md` file mechanically from `include/mruby/ops.h` file.
At the same time, the `doc/internal/opcode.md` file has been updated.
Consecutive hyphens at the end of the table were removed as they would have created noise as markdown flavours.
Exception raising can now be controlled by the caller.
The main purpose on this patch is:
- Suppress exceptions from `obj_free()` in `src/gc.c` with `mrb_env_unshare()`.
- Consider the possibility that calls to `mrb_malloc()` may cause `e` objects to be subject to GC.
When control is returned to `mrb_env_unshare()`, `struct free_obj::next` in the same offset as `struct REnv::stack` is rewritten.
Unexpected results then occur when the object is reused.
Also, if `mrb_heap_page` containing an `e` object is freed, it may cause `SIGSEGV` at that point.
- Protects the value of the stack on `callinfo` that just exits if GC occurs inside `mrb_env_unshare()`.
```ruby
def m
b = -> { b }
end
p m.call
# => print block object, not nil
```
This patch does not raise a `NoMemoryError` exception in `mrb_env_unshare()` and can detect that error.
Thus, the problem fixed in # 3087 is not resurrected.
Also, it may seem that this patch should suppress exceptions raised by `cipop()` during `mrb_protect_error()` and `mrb_vm_exec()` unwinds.
However, `mrb_callinfo::u.env` by `CINFO_DIRECT` is not seen to be set.
So in that case `mrb_env_unshare()` is assumed to be originally exception-free.
The mrbgem guide (`doc/guides/mrbgems.md`) documents the `path:`
argument for `conf.gem` as being used to point to the root directory
of a gem when that gem is retrieved via git but is located in a
subdirectory of the checkout.
The actual code does not do this. Instead, it treats path as (mostly)
identical to the `gemdir:` argument; that is, it points to a local
directory containing the gem.
This change fixes this by making `path:` behave as documented.
This was the cause of the command line flag being affected by changes in the parent build.
So, for example, if `mruby-rational` was included, even the automatically added `mrbc` builds included `MRB_USE_RATIONAL`.
Each build target can be explicitly disabled from benchmarking with `MRuby::Build#disable_benchmark`.
Also, the build target "host", which was previously excluded, is now included in the benchmark.
- Converted LoadGems::load_special_path_gems() into a class, then
subdivided the various types of gem dependencies into smaller
private methods.
- Added class GemDepDetails to hold the relationship between a gem's
location on the local disk and its upstream repository. This will
be used later.
- Removed the last remains of the '--pull-gems' option from the code
base and documentation. This is no longer present and the dead code
is clutter.
Gracefully handle the case where multiple gems use the same git checkout path.
Previously, if two gems had the same directory name when cloning them
from git, mrbgems would assume they were the same gem. This also
applied to different branches and/or commits of the same repository.
This led to a strange situation where the first `conf.gem` statement
"won" in cloning the repository but the last `conf.gem` ended up
choosing the branch/commit-id to use.
This change detects this situation and makes it an error. It also
allows the config writer to explicitly specify a gem checkout to use
in place of the others.
This adds a build_config that will cross-build a Windows executable
using the MinGW cross-compiler and will also run the unit (i.e.
'rake test') using Wine.
For this to work, I made some modifications to the underlying test
scripts as well as some minor changes to a couple of the tests
themselves.
When `disable_cdump` is declared on a Mrbgem spec, the procedure for
loading MRuby code from the gem's `mrblib` directory is slightly
different; instead of loading the mrblib code as a Proc built from the
compiled irep, the compiled irep is loaded directly. The header files
`mruby.h` and `mruby/proc.h` are needed only when the irep is loaded
directly. They are currently included only when presym is disabled, they
should be included whenever either presym is disabled *or* when
`disable_cdump` is called. The `cdump?` predicate method happens to
return true in either case (presym disabled *or* cdump disabled), so
this change should be safe.
If I break out of a block given to `MRuby::Build.new` with `break` or `throw`, I will get a seemingly inexplicable error because the `presym`-related initialization is not done.
```console
% cat build_config1.rb
MRuby::Build.new do
toolchain
break
end
% rake CONFIG=build_config1.rb
rake aborted!
external mrbc or mruby-bin-mrbc gem in current('host') or 'host' build is required
/var/tmp/mruby/lib/mruby/build.rb:332:in `mrbcfile'
/var/tmp/mruby/tasks/mrblib.rake:9:in `block in <top (required)>'
/var/tmp/mruby/lib/mruby/build.rb:18:in `instance_eval'
/var/tmp/mruby/lib/mruby/build.rb:18:in `block in each_target'
/var/tmp/mruby/lib/mruby/build.rb:17:in `each'
/var/tmp/mruby/lib/mruby/build.rb:17:in `each_target'
/var/tmp/mruby/tasks/mrblib.rake:1:in `<top (required)>'
/var/tmp/mruby/Rakefile:27:in `load'
/var/tmp/mruby/Rakefile:27:in `<top (required)>'
(See full trace by running task with --trace)
```
If a non-exceptional global jump occurs, it can be initialized by `ensure` to solve this problem.
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.
If we modify an option that may have been specified by users, we may
make unintended changes, so it is better not to modify it as much as
possible, IMO.
Because a structure that is an element of `presym_table` has padding, split
it into individual arrays for name and length.
#### Result (64-bit CPU with full-core gembox)
| | mruby | libmruby.a |
|--------|------------|------------|
| Before | 1,087,444B | 1,476,872B |
| After | 1,079,340B | 1,469,784B |
Yukihiro "Matz" Matsumoto