| Age | Commit message (Collapse) | Author |
|---|
|
Prohibit setting instance variables of existing classes and modules
via link.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://github.com/ruby/ruby/pull/10630#discussion_r1579565056
The PR was merged before I had a chance to address this feedback.
`assert_separately` is not necessary for this test if I don't use a
global timeout.
|
|
https://bugs.ruby-lang.org/issues/20228 started freeing `stk_base` to
avoid a memory leak. But `stk_base` is sometimes stack allocated (using
`xalloca`), so the free only works if the regex stack has grown enough
to hit `stack_double` (which uses `xmalloc` and `xrealloc`).
To reproduce the problem on master and 3.3.1:
```ruby
Regexp.timeout = 0.001
/^(a*)x$/ =~ "a" * 1000000 + "x"'
```
Some details about this potential fix:
`stk_base == stk_alloc` on
[init](https://github.com/ruby/ruby/blob/dde99215f2bc60c22a00fc941ff7f714f011e920/regexec.c#L1153),
so if `stk_base != stk_alloc` we can be sure we called
[`stack_double`](https://github.com/ruby/ruby/blob/dde99215f2bc60c22a00fc941ff7f714f011e920/regexec.c#L1210)
and it's safe to free. It's also safe to free if we've
[saved](https://github.com/ruby/ruby/blob/dde99215f2bc60c22a00fc941ff7f714f011e920/regexec.c#L1187-L1189)
the stack to `msa->stack_p`, since we do the `stk_base != stk_alloc`
check before saving.
This matches the check we do inside
[`stack_double`](https://github.com/ruby/ruby/blob/dde99215f2bc60c22a00fc941ff7f714f011e920/regexec.c#L1221)
|
|
|
|
In cases where RubyVM::InstructionSequence.load_from_binary() is
passed a param other than a String, we attempt to call the
RSTRING_LENINT macro on it which can cause a segfault.
ex:
```
var_0 = 0
RubyVM::InstructionSequence.load_from_binary(var_0)
```
This commit adds a type check to raise unless we are provided
a String.
|
|
[Feature #18576]
Since outright renaming `ASCII-8BIT` is deemed to backward incompatible,
the next best thing would be to only change its `#inspect`, particularly
in exception messages.
|
|
if a method `foo` uses a block, other (unrelated) method `foo`
can receives a block. So try to relax the unused block warning
condition.
```ruby
class C0
def f = yield
end
class C1 < C0
def f = nil
end
[C0, C1].f{ block } # do not warn
```
|
|
Accecpt the same arguments as `caller` and `caller_locations`.
|
|
|
|
This test fail relatively frequently and it's unclear what is
happening.
```
str: {"address":"0x7fbdeb26d4e0", "type":"STRING", "shape_id":1, "slot_size":40, "class":"0x7fbdd1e0ec50", "frozen":true, "embedded":true, "fstring":true, "bytesize":3, "value":"bar", "encoding":"UTF-8", "coderange":"7bit", "memsize":40, "flags":{"wb_protected":true, "old":true, "uncollectible":true, "marked":true}}
bar: {"address":"0x7fbdd0a8b138", "type":"STRING", "shape_id":1, "slot_size":40, "class":"0x7fbdd1e0ec50", "frozen":true, "embedded":true, "fstring":true, "bytesize":3, "value":"bar", "encoding":"UTF-8", "coderange":"7bit", "memsize":40, "flags":{"wb_protected":true}}
```
The `"bar".freeze` literal correctly put an old-gen fstring on the stack.
But `-%w(b a r).join('')` returns a young-gen fstring, which suggest it
somehow failed to find the old one in the `frozen_strings` table.
This could be caused by another test corrupting the table, or corrupting
the `"bar"` fstring.
By using a different literal value we can learn whether the bug is specific
to `"bar"` (used in many tests) or more general.
|
|
```ruby
b = RubyVM::InstructionSequence.compile('def f = yield; def g = nil').to_a
pp b
#=>
...
{:use_block=>true},
...
```
|
|
|
|
This makes it easier to notice a dependency is causing interpreter or
JIT deoptimization.
```ruby
Warning[:performance] = true
class String
def freeze
super
end
end
```
```
./test.rb:4: warning: Redefining 'String#freeze' disable multiple interpreter and JIT optimizations
```
|
|
|
|
Not along after 1b830740ba8371c4bcfdfc6eb2cb7e0ae81a84e0 CI
started to rarely fail this test:
```
TestString#test_uplus_minus: Test::Unit::AssertionFailedError: uminus deduplicates [Feature #13077].
1) Failure:
TestString#test_uplus_minus [/tmp/ruby/src/trunk/test/ruby/test_string.rb:3368]:
```
It's unclear what is going on, but one possibility is that
`"bar".freeze` might no longer compile correctly.
Another possibility is that another test redefine `String#freeze`,
causing `opt_str_freeze` to no longer return an `fstring`.
|
|
`super(){}`, `super{}` and `super(&b)` doesn't use the given
block so warn unused block warning when calling a method which
doesn't use block with above `super` expressions.
e.g.: `def f = super{B1}` (warn on `f{B2}` because `B2` is not used.
|
|
`super()` (not zsuper) passes the passed block and
it can be used.
```ruby
class C0
def foo; yield; end
end
class C1 < C0
def foo; super(); end
end
C1.new.foo{p :block} #=> :block
```
|
|
With verbopse mode (-w), the interpreter shows a warning if
a block is passed to a method which does not use the given block.
Warning on:
* the invoked method is written in C
* the invoked method is not `initialize`
* not invoked with `super`
* the first time on the call-site with the invoked method
(`obj.foo{}` will be warned once if `foo` is same method)
[Feature #15554]
`Primitive.attr! :use_block` is introduced to declare that primitive
functions (written in C) will use passed block.
For minitest, test needs some tweak, so use
https://github.com/minitest/minitest/commit/ea9caafc0754b1d6236a490d59e624b53209734a
for `test-bundled-gems`.
|
|
In cases where `rb_ary_sort_bang` is called with a block and
tmp is an embedded array, we need to account for the block
potentially impacting the capacity of ary.
ex:
```
var_0 = (1..70).to_a
var_0.sort! do |var_0_block_129, var_1_block_129|
var_0.pop
var_1_block_129 <=> var_0_block_129
end.shift(3)
```
The above example can put the array into a corrupted state
resulting in a heap buffer overflow and possible segfault:
```
ERROR: AddressSanitizer: heap-buffer-overflow on address [...]
WRITE of size 560 at 0x60b0000034f0 thread T0 [...]
```
This commit adds a conditional to determine when the capacity
of ary has been modified by the provided block. If this is
the case, ensure that the capacity of ary is adjusted to
handle at minimum the len of tmp.
|
|
We don't need to treat static symbols in any special way since they
can't be confused with other special consts or GC managed objects.
|
|
|
|
|
|
The `rb_fstring(rb_enc_str_new())` pattern is inneficient because:
- It passes a mutable string to `rb_fstring` so if it has to be interned
it will first be duped.
- It an equivalent interned string already exists, we allocated the string
for nothing.
With `rb_enc_interned_str` we either directly get the pre-existing string
with 0 allocations, or efficiently directly intern the one we create
without first duping it.
|
|
|
|
|
|
Additional flags are comma separated list preceeded by `-` or `+`.
Before:
```sh
$ ruby --dump=insns+without_opt
```
After:
```sh
$ ruby --dump=insns-opt,-optimize
```
At the same time, `parsetree_with_comment` is split to `parsetree`
option and additional `comment` flag.
Before:
```sh
$ ruby --dump=parsetree_with_comment
```
After:
```sh
$ ruby --dump=parsetree,+comment
```
Also flags can be separate `--dump`.
```sh
$ ruby --dump=parsetree --dump=+comment --dump=+error_tolerant
```
Ineffective flags are ignored silently.
```sh
$ ruby --dump=parsetree --dump=+comment --dump=+error_tolerant
```
|
|
|
|
|
|
- Make `make_tempfile` to take data to write, `binmode:` flag, and a
block.
- Use `make_tempfile` instead of `make_tempfile0`.
- Use `File.binwrite`.
|
|
This patch suggests relocating the code dealing with `SCRIPT_LINES__` from ast.c to ruby_parser.c.
## Background
- I guess `AbstractSyntaxTree.of` method used to use `SCRIPT_LINES__` internally for some reason before
- However, now it appears `SCRIPT_LINES__` is no longer used meaningfully by the method
- As evidence of this, (and as my patch shows,) removing the function call of `rb_script_lines_for()` from `ast_s_of()` does not affect the result of `test/ruby/test_ast.rb`
Given the above, I think two possibilities can be considered:
- (A) `AbstractSyntaxTree.of` has not needed `SCRIPT_LINES__` already (I pick this)
- (B) We lack a test case of `AbstractSyntaxTree.of` that needs to use `SCRIPT_LINES__`
## Besides,
The current implementation causes strange behavior:
```console
ruby -e"SCRIPT_LINES__ = {__FILE__ => []}; puts RubyVM::AbstractSyntaxTree.of(->{ 1 + 2 }, keep_script_lines: true).script_lines"
=> `-e:1:in '<main>': undefined method 'script_lines' for nil (NoMethodError)`
```
I think this is a bug because `AbstractSyntaxTree.of` is not supposed to return `nil` even in this case.
This happens due to the ast.c's dependence on `SCRIPT_LINES__`.
And at the end of the `ast_s_of()`, `node_find()` can not find the target child node obviously because it doesn't make sense to look for a corresponding node made from the parameter of `AbstractSyntaxTree.of` in the AST tree made from the value of `{__FILE__ => []}`
## Solution
Since I think it's good enough `SCRIPT_LINES__` to be only referred by ruby.c, I chose the possibility "(A)" and wrote this patch which moves `rb_script_lines_for()` from ast.c to ruby_parser.c.
So as the result:
- `ast_s_of()` function no longer look up `SCRIPT_LINES__`
- Even so, this patched code passes the existing tests
- The strange behavior above no longer happens (I also added a test for it)
Please correct me if I miss something🙏
|
|
```
[19889/25837] TestArgf#test_puts-e:1: warning: ARGF.class#write is outdated interface which accepts just one argument
= 0.06 s
```
https://rubyci.s3.amazonaws.com/debian12/ruby-master/log/20240404T033003Z.log.html.gz
|
|
|
|
|
|
|
|
Launchable reported that this was the most "flaky" test. Perhaps the
default timeout (10 seconds) is too tight for a test that uses
`GC.stress = true`. I try to relax the limit.
|
|
clause duplication
This commit simplifies warnings for hash keys duplication and when clause duplication,
based on the discussion of https://bugs.ruby-lang.org/issues/20331.
Warnings are reported only when strings are same to ohters.
|
|
By default, ASAN sets RLIMIT_CORE to zero, "to avoid dumping a 16T+ core
file" on 64 bit systems. These tests are just asserting on the expected
value of RLIMIT_CORE, not actually dumping core files, so it's fine to
disable that behaviour of ASAN for this test.
|
|
ASAN registers a sigsegv handler and causes extra output to be emitted
that these tests are not expecting.
|
|
|
|
These are designed to prevent allocation regressions (commits that
increase the number of implicitly allocated arrays and hashes). We
have already had three commits in the last couple weeks to fix
allocation regressions:
* 15dc3aaa311b32203d8ffb414bcf9b8e55ce5691
* aceee71c35e0b387691836e756b4e008efd84cf1
* c38878494377c94f2425a81e598260ea944ef7f3
This test suite should hopefully allow us to find such regressions
in CI before commit, to avoid committing future allocation regressions.
This uses assert_separately around each set of tests. Doing it for
each individual check was too slow. Failures are gathered and
reported at the end of the the suite as a single assertion, with
the message describing all failures.
|
|
This reverts commit 3680981c7b71df8c3a426164787ccefe5296bb25.
|
|
Signed-off-by: crazeteam <lilujing@outlook.com>
|
