When `OP_GETUPVAR` is generated right after `OP_SETUPVAR`, there is no
need to read the upvar back to the register, e.g.
3 008 OP_ADDI R2 1
3 011 OP_SETUPVAR R2 1 0
4 015 OP_GETUPVAR R2 1 0
4 019 OP_LOADI_2 R3
`OP_GETUPVAR` at the address `015` is useless. We can skip it like:
3 008 OP_ADDI R2 1
3 011 OP_SETUPVAR R2 1 0
4 015 OP_LOADI_2 R3
This reverts commit fd10c72319.
I thought it was OK to restrict index value within 1 byte, but in some
cases index value could be 16 bits (2 bytes). I had several ideas to
address the issue, but reverting `fd10c72` is the easiest way. The
biggest reason is `mruby/c` still supports `OP_EXT[123]`, so that they
don't need any additional work.
Previously the following code did not produce the expected results:
```ruby
bx = binding
block = bx.eval("a = 1; proc { a }")
bx.eval("a = 2")
p block.call # Expect 2 but return 1 due to a bug
```
The previous implementation of `Binding#eval` evaluated the code and then merged the top layer variables.
This patch will parse and expand the variable space before making a call to `eval`.
This means that the call to `Binding#eval` will do the parsing twice.
In addition, the following changes will be made:
- Make `mrb_parser_foreach_top_variable()`, `mrb_binding_extract_proc()` and `mrb_binding_extract_env()` functions private global functions.
- Remove the `posthook` argument from `mrb_exec_irep()`.
The `posthook` argument was introduced to implement the `binding` method.
This patch is unnecessary because it uses a different implementation method.
ref #5362fixed#5491
If no new variable was defined in the `eval` method, the variable was hidden from the nested `eval` method.
```ruby
a = 1
p eval %(b = 2; eval %(a)) # => 1 (good)
p eval %(eval %(a)) # => undefined method 'a' (NoMethodError)
```
This issue has occurred since mruby 3.0.0.
* renamed from redundant `readint_mrb_int()`
* supports only base upto 16
* no base validation (already done in parser)
* no negative read (negate after read)
* overflow detection using `mrb_int_{mul,add}_overflow()`
The GitHub Super Linter is a more robust and better supported
tool than the current GitHub Actions we are using.
Running these checks:
ERROR_ON_MISSING_EXEC_BIT: true
VALIDATE_BASH: true
VALIDATE_BASH_EXEC: true
VALIDATE_EDITORCONFIG: true
VALIDATE_MARKDOWN: true
VALIDATE_SHELL_SHFMT: true
VALIDATE_YAML: true
https://github.com/marketplace/actions/super-linterhttps://github.com/github/super-linter
Added the GitHub Super Linter badge to the README.
Also updated the pre-commit framework and added
more documentation on pre-commit.
Added one more pre-commit check: check-executables-have-shebangs
Added one extra check for merge conflicts to our
GitHub Actions.
EditorConfig and Markdown linting.
Minor grammar and spelling fixes.
Update linter.yml
When argument information is not available. So it should not happen for
`yield` (error). In contrast, the error from `super` should be handled
in run time (ignored).
Add new pool value type `IREP_TT_BIGINT` and generate integer overflow
error in the VM. In the future, `mruby` will support `Bignum` for
integers bigger than `mrb_int` (probably using `mpz`).
Normally a single spell checker can't find all the mistakes or check all types of code.
These mistakes were found by another spell checker inside my editor with a more manual sift / find.
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.
Yukihiro "Matz" Matsumoto