- 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.
mruby expects `malloc(3)` returns `NULL` for too big allocations, so
even if big object allocation (e.g. `[1,2,3]*268888888888888818`)
caused ASAN/Valgrind warnings, it's intentional, and we won't consider
the warning as a security issue.
- Changed the description to match the order of the changed members.
- Replaced "array of symbols" instead of "array of strings that mean symbols".
- The `mrb_kwargs::optional` member has not been present since the first merge. It is a remnant from development time.
- Removed `const` modifier used in variable declarations in examples. This is not always necessary from a user perspective.
- Added note on the use of `MRB_SYM()`.
resolved#5649
I expect this will fix the two problems that "#5640" didn't address.
- It is expected to raise an exception `TypeError`, but it didn't before.
```console
% bin/mruby -e 'p [**1]'
[1]
```
- The variable `h` is expected to keep an empty hash, but it didn't before.
```console
% bin/mruby -e 'h = {}; p(**h, a: 1, b: 2); p h'
{:a=>1, :b=>2}
{:a=>1, :b=>2}
```
## Summary
This following is a behavior from CRuby 1.8.7 to 3.1.0.
```console
% ruby -ve "p ['a', 'b', 'c']*''"
ruby 1.8.7 (2013-12-22 patchlevel 375) [i686-darwin13.0.2]
"abc"
% ruby -ve "p ['a', 'b', 'c']*''"
ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin19]
"abc"
```
### Before (mruby 3.0.0)
mruby unexpectedly gives the TypeError.
```ruby
['a', 'b', 'c']*'' #=> String cannot be converted to Integer (TypeError)
```
### After
This PR makes mruby behave compatible with CRuby.
```ruby
['a', 'b', 'c']*'' #=> 'abc'
```
As far as I checked, the behavior is unspecified when `Array#*`'s argument
is not an instance of Integer class in X 3017 : 2013 (ISO/IEC 30170 : 2012).
## Additional Information
I noticed this difference by the following idiom when writing ASCII art code
using Ruby.
```ruby
%w(foo bar baz)*''
```
e.g. TRICK (https://github.com/tric)
We used to check them by `mrb_ensure_xxx_type()` functions, but type
errors there should not occur if there's no bug in code generations.
So we use assertion rather than dynamic type checks.
Yukihiro "Matz" Matsumoto