CRuby 3.4 puts spaces around `=>` since for example `{:a!=>2}` can be
confusing where to separate tokens. mruby should follow the behavior.
Many tests in `test/t` directory assumed no spaces around `=>`, so we
needed to fix them too.
When multiple identical proc objects are placed on the call stack, it is not possible to distinguish where to `return`.
Therefore, use env object comparisons to do this.
fixed#6411
It used to check all `start`, `end` and `step`. If either of them are
float number, `#step` iterated over float number. Now we don't check the
type of `end` argument.
`string[]=(idx, replace)` should return `replace`.
## Actual (wrong)
```
string.[]=(idx, replace) → string
string.[]=(idx, len, replace) → string
```
## Expected
```
string.[]=(idx, replace) → replace
string.[]=(idx, len, replace) → replace
```
## Sidenote
As of the current mruby-compiler, `(string[idx] = 'X')` creates not only "CALL_NODE" but also "ASGN_NODE" and "OP_MOVE", overriding the wrong return value.
On the other hand, `string.[]=(idx, 'X')` creates only "CALL_NODE", exposing the wrong return value.
If my new mruby-compiler2, leveraging Prism, took the place of official compiler, `(string[idx] = 'X')` and `string.[]=(idx, 'X')` would be going to generate the same VM code without "OP_MOVE".
So I paranoidly added tests.
FYI: You can find how the new mruby-compiler2's AST and VM code look like in mruby/c's issue (mruby/c had the same bug): https://github.com/mrubyc/mrubyc/pull/210
This will be a partial merge of #5317 with the following changes.
- Remove `iclass->iv_c` since `iclass->iv_c` is equivalent to `iclass->c`.
- `class_iv_ptr()` returns a single pointer instead of a double pointer.
mruby used to use float numbers for overflown integers before we
implemented big integers. Now we don't need bit operations for float
numbers anymore. Also removed tests for shift operations for float
numbers.
Previously, for example, it was possible to retrieve the `String` class as follows:
```console
% bin/mruby -e 'p Comparable::Enumerable::Errno::GC::Kernel::Math::ObjectSpace::String'
String
```
Note that this patch affects the API function `mrb_const_get()`.
## 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)
Yukihiro "Matz" Matsumoto