[#104740] [Ruby master Feature#18057] Introduce Array#average — ggmichaelgo@...

Issue #18057 has been reported by ggmichaelgo (Michael Go).

14 messages 2021/08/02

[#104774] [Ruby master Bug#18061] Execshield test: libruby.so.N.N.N: FAIL: property-note test because no .note.gnu.property section found — jaruga@...

Issue #18061 has been reported by jaruga (Jun Aruga).

48 messages 2021/08/04

[#104780] [Ruby master Bug#18062] Ruby with enabled LTO segfaults during build — v.ondruch@...

Issue #18062 has been reported by vo.x (Vit Ondruch).

30 messages 2021/08/05

[#104831] [Ruby master Bug#18066] Load did_you_mean eve/error_highlight even with --disable-gems — v.ondruch@...

Issue #18066 has been reported by vo.x (Vit Ondruch).

10 messages 2021/08/07

[#104851] [Ruby master Bug#18073] test/ruby/test_jit.rb: failures "error: invalid use of '__builtin_va_arg_pack ()'" on Ruby 2.7.4 on gcc 4.8.5 on RHEL7 — jaruga@...

Issue #18073 has been reported by jaruga (Jun Aruga).

14 messages 2021/08/09

[#104927] [Ruby master Bug#18077] Marshal.dump(closed_io) raises IOError instead of TypeError — "larskanis (Lars Kanis)" <noreply@...>

Issue #18077 has been reported by larskanis (Lars Kanis).

10 messages 2021/08/16

[#104960] [Ruby master Feature#18083] Capture error in ensure block. — "ioquatix (Samuel Williams)" <noreply@...>

Issue #18083 has been reported by ioquatix (Samuel Williams).

32 messages 2021/08/18

[#105021] [Ruby master Misc#18122] DevelopersMeeting20210916Japan — "mame (Yusuke Endoh)" <noreply@...>

Issue #18122 has been reported by mame (Yusuke Endoh).

12 messages 2021/08/20

[#105069] [Ruby master Bug#18133] LTO: TestGCCompact#test_ast_compacts segfaults on i686 — "vo.x (Vit Ondruch)" <noreply@...>

Issue #18133 has been reported by vo.x (Vit Ondruch).

25 messages 2021/08/25

[#105077] [Ruby master Feature#18136] take_while_after — "zverok (Victor Shepelev)" <noreply@...>

Issue #18136 has been reported by zverok (Victor Shepelev).

21 messages 2021/08/27

[ruby-core:104996] [Ruby master Bug#15404] Endless range has inconsistent chaining behaviour

From: "matz (Yukihiro Matsumoto)" <noreply@...>
Date: 2021-08-19 07:18:04 UTC
List: ruby-core #104996
Issue #15404 has been updated by matz (Yukihiro Matsumoto).

Status changed from Open to Rejected

I think it's OK to keep the current behavior. `1.. ..2` looks weird, I agree, but don't need to be a syntax error.

Matz.


----------------------------------------
Bug #15404: Endless range has inconsistent chaining behaviour
https://bugs.ruby-lang.org/issues/15404#change-93395

* Author: valich (Valentin Fondaratov)
* Status: Rejected
* Priority: Normal
* 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>

In This Thread

Prev Next