[#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
naruse@airemix.jp 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 <headius@headius.com> 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@...>
k0kubun@ruby-lang.org wrote:
3 messages
2018/12/30
[ruby-core:90450] [Ruby trunk Bug#15404] Endless range has inconsistent chaining behaviour
From:
mame@...
Date:
2018-12-12 15:44:07 UTC
List:
ruby-core #90450
Issue #15404 has been updated by mame (Yusuke Endoh).
Thank you for your report.
valich (Valentin Fondaratov) wrote:
> ## 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.
I understand the problem. But, it is not specific to endless range, is it? In fact, `(1..1)..1` does parse, and fails to run.
It is possible to prohibit all nested range, including a non-endless range `(1..1)..1` and an endless range `(1..)..1`. This brings very small incompatibility which is acceptable IMO.
Nobu's patch:
```diff
diff --git i/parse.y w/parse.y
index 278c5b0296..1c76af541a 100644
--- i/parse.y
+++ w/parse.y
@@ -380,6 +380,8 @@ static void void_expr(struct parser_params*,NODE*);
static NODE *remove_begin(NODE*);
static NODE *remove_begin_all(NODE*);
#define value_expr(node) value_expr_gen(p, (node) = remove_begin(node))
+static int range_expr_gen(struct parser_params*,NODE*);
+#define range_expr(node) range_expr_gen(p, (node) = remove_begin(node))
static NODE *void_stmts(struct parser_params*,NODE*);
static void reduce_nodes(struct parser_params*,NODE**);
static void block_dup_check(struct parser_params*,NODE*,NODE*);
@@ -1909,8 +1911,8 @@ arg : lhs '=' arg_rhs
| arg tDOT2 arg
{
/*%%%*/
- value_expr($1);
- value_expr($3);
+ range_expr($1);
+ range_expr($3);
$$ = NEW_DOT2($1, $3, &@$);
/*% %*/
/*% ripper: dot2!($1, $3) %*/
@@ -1918,8 +1920,8 @@ arg : lhs '=' arg_rhs
| arg tDOT3 arg
{
/*%%%*/
- value_expr($1);
- value_expr($3);
+ range_expr($1);
+ range_expr($3);
$$ = NEW_DOT3($1, $3, &@$);
/*% %*/
/*% ripper: dot3!($1, $3) %*/
@@ -1931,7 +1933,7 @@ arg : lhs '=' arg_rhs
loc.beg_pos = @2.end_pos;
loc.end_pos = @2.end_pos;
- value_expr($1);
+ range_expr($1);
$$ = NEW_DOT2($1, new_nil(&loc), &@$);
/*% %*/
/*% ripper: dot2!($1, Qnil) %*/
@@ -1943,7 +1945,7 @@ arg : lhs '=' arg_rhs
loc.beg_pos = @2.end_pos;
loc.end_pos = @2.end_pos;
- value_expr($1);
+ range_expr($1);
$$ = NEW_DOT3($1, new_nil(&loc), &@$);
/*% %*/
/*% ripper: dot3!($1, Qnil) %*/
@@ -9540,6 +9542,18 @@ value_expr_gen(struct parser_params *p, NODE *node)
return TRUE;
}
+static int
+range_expr_gen(struct parser_params *p, NODE *node)
+{
+ switch (nd_type(node)) {
+ case NODE_DOT2:
+ case NODE_DOT3:
+ yyerror1(&node->nd_loc, "nested range");
+ return FALSE;
+ }
+ return value_expr_gen(p, node);
+}
+
static void
void_expr(struct parser_params *p, NODE *node)
{
```
@matz and @naruse, can we commit it? Is it okay to reject `(1..1)..1` as a parse error?
----------------------------------------
Bug #15404: Endless range has inconsistent chaining behaviour
https://bugs.ruby-lang.org/issues/15404#change-75610
* Author: valich (Valentin Fondaratov)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: ruby 2.6.0rc1 (2018-12-06 trunk 66253) [x86_64-linux]
* 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:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>