[#90399] [Ruby trunk Feature#14813] [PATCH] gc.c: make gc_enter+gc_exit pairs dtrace probes, too — ko1@...
Issue #14813 has been updated by ko1 (Koichi Sasada).
3 messages
2018/12/10
[#90417] [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD — naruse@...
Issue #15398 has been reported by naruse (Yui NARUSE).
4 messages
2018/12/11
[#90423] Re: [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD
— Eric Wong <normalperson@...>
2018/12/11
[email protected] wrote:
[#90519] Spoofing warnings for mail from bugs.ruby-lang.org — Charles Oliver Nutter <headius@...>
I'm getting a spoofing warning for emails sent from bugs.ruby-lang.org when
4 messages
2018/12/13
[#90522] Re: Spoofing warnings for mail from bugs.ruby-lang.org
— Eric Wong <normalperson@...>
2018/12/13
Charles Oliver Nutter <[email protected]> wrote:
[#90533] [Ruby trunk Feature#15413] unmarkable C stack (3rd stack) — normalperson@...
Issue #15413 has been reported by normalperson (Eric Wong).
3 messages
2018/12/14
[#90581] [Ruby trunk Bug#15424] Ruby 2.6.0rc1 & 2.6.0rc2 mutex exception — mat999@...
Issue #15424 has been reported by splitice (Mathew Heard).
3 messages
2018/12/17
[#90595] [Ruby trunk Bug#15430] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been reported by hsbt (Hiroshi SHIBATA).
3 messages
2018/12/18
[#90614] [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been updated by hsbt (Hiroshi SHIBATA).
4 messages
2018/12/19
[#90630] Re: [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI
— Eric Wong <normalperson@...>
2018/12/20
> It still exists. https://rubyci.org/logs/rubyci.s3.amazonaws.com/centos7/ruby-trunk/log/20181218T230003Z.fail.html.gz
[#90820] Re: [ruby-cvs:73697] k0kubun:r66593 (trunk): accept_nonblock_spec.rb: skip spurious failure — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/12/30
[ruby-core:90447] [Ruby trunk Bug#15404] Endless range has inconsistent chaining behaviour
From:
fondarat@...
Date:
2018-12-12 13:08:57 UTC
List:
ruby-core #90447
Issue #15404 has been reported by valich (Valentin Fondaratov). ---------------------------------------- Bug #15404: Endless range has inconsistent chaining behaviour https://bugs.ruby-lang.org/issues/15404 * Author: valich (Valentin Fondaratov) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: 2.6.0-rc1 * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Everything below is tested on `Ruby 2.6.0-rc1`. Particular sexp column coordinates are wrong because I've had some leading spaces in the file, sorry. ## The essence of the bug Syntactically, chaining normal ranges is prohibited. For example, `(1..1)..1` produces the following sexp output: ``` [:program, [[:dot2, [:paren, [[:dot2, [:@int, "1", [1, 16]], [:@int, "1", [1, 19]]]]], [:@int, "1", [1, 23]]]]] ``` while `1..1..1` is a syntax error (compiler output: `syntax error, unexpected ..`) New endless ranges break this behaviour and allow chaining. There are two bugs. 1. Chaining is possible on one line: `1.. ..1` is parsed as ``` [:program, [[:dot2, [:dot2, [:@int, "1", [1, 15]], nil], [:@int, "1", [1, 21]]]]] ``` I think this is inconsistent compared to the previous case. 2. Chaining works even with newline between two parts: ``` 1.. ..1 ``` ``` [:program, [[:dot2, [:dot2, [:@int, "1", [1, 15]], nil], [:@int, "1", [2, 17]]]]] ``` This behaviour is completely counterintuitive because `1..` on the first line is a complete statement. Even if it continues to the next line with the search for the right part of expression (end range), it should break because `..1` is not a syntactically valid range end. So, in the search for the end range parser decides to complete the first range and use it as a beginning. It contradicts older ``` 1 ..2 ``` behaviour which effectively meant that a range could not be continued to the next line. ## Why it's important All the code above will break on runtime because it leads to `bad value for range (ArgumentError)`. However, if the code is located in some method (or branch) which is executed rarely, developer might miss the problem. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>