Issue #17925 has been updated by jeremyevans0 (Jeremy Evans).
@kddnewton Is this possible to fix in YARP?
@yui-knk Is this possible to fix in parse.y/lrama?
----------------------------------------
Bug #17925: Pattern matching syntax using semicolon one-line
https://bugs.ruby-lang.org/issues/17925#change-104311
* Author: koic (Koichi ITO)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19]
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
## Summary
There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior?
```console
% ruby -v
ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19]
% ruby -ce 'case expression when 42; end'
Syntax OK
% ruby -ce 'case expression in 42; end'
-e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby!
-e:1: syntax error, unexpected `end', expecting `when'
case expression in 42; end
```
So, I have two concerns.
- Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`?
- Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right?
This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1.
## Additional Information
NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax.
```
% ruby -ce 'expression in 42'
-e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby!
Syntax OK
```
NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit.
```
% ruby -e ruby -ce 'case expression; in 42; end'
Syntax OK
```
--
https://bugs.ruby-lang.org/
Issue #14387 has been updated by ojab (ojab ojab).
Any update on this?
----------------------------------------
Bug #14387: Ruby 2.5 を Alpine Linux で実行すると比較的浅めで SystemStackError 例外になる
https://bugs.ruby-lang.org/issues/14387#change-100931
* Author: koshigoe (Masataka SUZUKI)
* Status: Open
* Priority: Normal
* ruby -v: ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux-musl]
* Backport: 2.3: DONTNEED, 2.4: DONTNEED, 2.5: REQUIRED
----------------------------------------
CircleCI で Alpine Linux を使って Ruby 2.5.0 で Rubocop を実行した時に遭遇した例外です(Ruby 2.4.3 では発生しませんでした)。
Ruby のバージョンによって、再帰が止められるまでの回数に大きな違いがあるのはなぜでしょうか?
これは、意図された挙動なのか、Ruby の変更によるものでは無く Alpine Linux 固有の問題なのか、教えていただく事は可能でしょうか?
Alpine Linux の Tread stack size が比較的小さい事で、Ruby 2.5.0 からこのような挙動になったのでしょうか?
https://wiki.musl-libc.org/functional-differences-from-glibc.html#Thread-st…
## 再現
問題の再現のため、以下の様な再帰するコードを実行します。
~~~ ruby
# test.rb
n = 100000
res = {}
1.upto(n).to_a.inject(res) do |r, i|
r[i] = {}
end
def f(x)
x.each_value { |v| f(v) }
end
f(res)
~~~
Ruby 2.4.3 で実行した場合、 10061 levels で例外があがりました。
~~~
% docker container run \
-v (pwd):/mnt/my --rm \
ruby:2.4.3-alpine3.7 \
ruby -v /mnt/my/test.rb
ruby 2.4.3p205 (2017-12-14 revision 61247) [x86_64-linux-musl]
/mnt/my/test.rb:9:in `each_value': stack level too deep (SystemStackError)
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:9:in `block in f'
from /mnt/my/test.rb:9:in `each_value'
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:9:in `block in f'
from /mnt/my/test.rb:9:in `each_value'
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:9:in `block in f'
... 10061 levels...
from /mnt/my/test.rb:9:in `block in f'
from /mnt/my/test.rb:9:in `each_value'
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:12:in `<main>'
```
一方で Ruby 2.5.0 で実行した場合、 134 level で例外があがりました。
```
% docker container run \
-v (pwd):/mnt/my --rm \
test/ruby:trunk-alpine3.7 \
ruby -v /mnt/my/test.rb
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux-musl]
/mnt/my/test.rb:9:in `each_value': stack level too deep (SystemStackError)
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:9:in `block in f'
from /mnt/my/test.rb:9:in `each_value'
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:9:in `block in f'
from /mnt/my/test.rb:9:in `each_value'
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:9:in `block in f'
... 134 levels...
from /mnt/my/test.rb:9:in `block in f'
from /mnt/my/test.rb:9:in `each_value'
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:12:in `<main>'
```
また、Ruby trunk で実行した場合は 2.5.0 同等の結果になりました。
```
ruby 2.6.0dev (2018-01-24 trunk 62017) [x86_64-linux-musl]
/mnt/my/test.rb:9:in `each_value': stack level too deep (SystemStackError)
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:9:in `block in f'
from /mnt/my/test.rb:9:in `each_value'
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:9:in `block in f'
from /mnt/my/test.rb:9:in `each_value'
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:9:in `block in f'
... 134 levels...
from /mnt/my/test.rb:9:in `block in f'
from /mnt/my/test.rb:9:in `each_value'
from /mnt/my/test.rb:9:in `f'
from /mnt/my/test.rb:12:in `<main>'
```
※ trunk の Docker イメージを作った際の Dockerfile は以下。
https://gist.github.com/koshigoe/509be02a3580cdfc7a2cc45a4e6e44c5
---Files--------------------------------
0001-thread_pthread.c-make-get_main_stack-portable-on-lin.patch (2.61 KB)
--
https://bugs.ruby-lang.org/
Issue #19194 has been reported by make_now_just (Hiroya Fujinami).
----------------------------------------
Feature #19194: Add Regexp.linear_time?
https://bugs.ruby-lang.org/issues/19194
* Author: make_now_just (Hiroya Fujinami)
* Status: Open
* Priority: Normal
----------------------------------------
I suggest adding a new method named `Regexp.linear_time?` to check if matching against a given regexp can be completed in linear time by the optimization introduced in #19104 (GitHub PR [#6486](https://github.com/ruby/ruby/pull/6486)).
This method was discussed in #19104. I'm not sure the name is best.
# Example
```
Regexp.linear_time?(/a/) # => true
Regexp.linear_time?(/(a|a)*\1/) # => false, because this uses a back-reference.
# This can accept a regexp source string and flags like `Regexp.new`.
Regexp.linear_time?('a') # => true
Regexp.linear_time?('a', Regexp::IGNORECASE) # => true
```
For example, this method is useful for implementing a Rubocop rule to check a regexp is ReDoS safe.
# Implementation
Implementation is done at GitHub PR [#6901](https://github.com/ruby/ruby/pull/6901).
See the details there.
--
https://bugs.ruby-lang.org/
Issue #19193 has been reported by YO4 (Yoshinao Muramatsu).
----------------------------------------
Feature #19193: drop DOS TEXT mode support
https://bugs.ruby-lang.org/issues/19193
* Author: YO4 (Yoshinao Muramatsu)
* Status: Open
* Priority: Normal
----------------------------------------
On Windows platform, ```File.open(path, "r")``` returns an object different from "rt" and "rb". I call that DOS TEXT mode here.
DOS TEXT mode does
* crlf conversion
* 0x1a treated EOF charactor on read
and others (see Bug #19192).
But DOS TEXT mode is almost unnecessary today and it seems to introduce lot of code complexities.
Now there is less need for dos text mode
* Microsoft's most apps works without CRLF newline.
* Creating a crlf text file today should be explicit. (but that is default mode on windows now)
* Interpreting EOF charactor can cause trouble.
I think it's time to consider dropping DOS TEXT mode.
What challenges are there and what preparation is needed?
--
https://bugs.ruby-lang.org/
Issue #19134 has been updated by Eregon (Benoit Daloze).
shugo (Shugo Maeda) wrote in #note-14:
> Speaking of implicity of blocks, `def f; g(&); end` causes a syntax error, so it may be better to allow it, or disallow `def f(...); g(&); end` in the future versions.
Since some time @ko1 worked on no implicit block if not a parameter of the method (with the exception of `yield` in the body). I think that's a good property, so I think it's good for `def f; g(&); end` to be a syntax error.
For `def f(...); g(&); end` "..." is "capture all arguments, positional, keyword and block" so I think it's more natural there to be able to access the block (although I can't think of when that would be useful, maybe `def f(...); g(&); h(...) end` when `h` is known to ignore the block but that feels hacky, better use `(*, **, &)` parameters then).
> Anyway, I've fixed the behavior of `...` as described in #note-9.
Thanks!
----------------------------------------
Feature #19134: ** is not allowed in def foo(...)
https://bugs.ruby-lang.org/issues/19134#change-100680
* Author: shugo (Shugo Maeda)
* Status: Closed
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 3.2
----------------------------------------
`*` and `&` are allowed in the body of a method with `...` argument forwarding, but `**` is not allowed.
```
def foo(...)
bar(*) # OK
baz(&) # OK
quux(**) # NG
end
```
Is it intended behavior?
It seems that parse.y has code like `#ifdef RUBY3_KEYWORDS`, and if RUBY3_KEYWORDS, `**` will also be supported.
--
https://bugs.ruby-lang.org/
Issue #19134 has been updated by shugo (Shugo Maeda).
mame (Yusuke Endoh) wrote in #note-12:
> I feel that only `&` is acceptable since a block is implicitly passed. But I don't think `*` and `**` make sense inside `def foo(...)`.
Speaking of implicity of blocks, `def f; g(&); end` causes a syntax error, so it may be better to allow it, or disallow `def f(...); g(&); end` in the future versions.
Anyway, I've fixed the behavior of `...` as described in #note-9.
----------------------------------------
Feature #19134: ** is not allowed in def foo(...)
https://bugs.ruby-lang.org/issues/19134#change-100678
* Author: shugo (Shugo Maeda)
* Status: Closed
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 3.2
----------------------------------------
`*` and `&` are allowed in the body of a method with `...` argument forwarding, but `**` is not allowed.
```
def foo(...)
bar(*) # OK
baz(&) # OK
quux(**) # NG
end
```
Is it intended behavior?
It seems that parse.y has code like `#ifdef RUBY3_KEYWORDS`, and if RUBY3_KEYWORDS, `**` will also be supported.
--
https://bugs.ruby-lang.org/
Issue #19134 has been updated by mame (Yusuke Endoh).
> IMHO if ... is used then *, ** and & should all be forbidden (a SyntaxError at parse time).
I agree with this. If you want to do that, you should take it with `def foo(*, **, &)`.
I feel that only `&` is acceptable since a block is implicitly passed. But I don't think `*` and `**` make sense inside `def foo(...)`.
----------------------------------------
Feature #19134: ** is not allowed in def foo(...)
https://bugs.ruby-lang.org/issues/19134#change-100630
* Author: shugo (Shugo Maeda)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 3.2
----------------------------------------
`*` and `&` are allowed in the body of a method with `...` argument forwarding, but `**` is not allowed.
```
def foo(...)
bar(*) # OK
baz(&) # OK
quux(**) # NG
end
```
Is it intended behavior?
It seems that parse.y has code like `#ifdef RUBY3_KEYWORDS`, and if RUBY3_KEYWORDS, `**` will also be supported.
--
https://bugs.ruby-lang.org/
Issue #19134 has been updated by Eregon (Benoit Daloze).
shugo (Shugo Maeda) wrote in #note-8:
> `&` is allowed in 3.1, so it's a breaking change to prohibit it.
Right and `&` is not problematic re performance, it's a completely separate argument anyway.
I agree with your proposal in your comment just above this one.
----------------------------------------
Feature #19134: ** is not allowed in def foo(...)
https://bugs.ruby-lang.org/issues/19134#change-100573
* Author: shugo (Shugo Maeda)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 3.2
----------------------------------------
`*` and `&` are allowed in the body of a method with `...` argument forwarding, but `**` is not allowed.
```
def foo(...)
bar(*) # OK
baz(&) # OK
quux(**) # NG
end
```
Is it intended behavior?
It seems that parse.y has code like `#ifdef RUBY3_KEYWORDS`, and if RUBY3_KEYWORDS, `**` will also be supported.
--
https://bugs.ruby-lang.org/