- ruby-core - ml.ruby-lang.org

[ruby-core:115793] [Ruby master Bug#20073] Method lookup incorrect with `--parser=prism`
by eightbitraptor (Matthew Valentine-House) 19 Dec '23

19 Dec '23

Issue #20073 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Bug #20073: Method lookup incorrect with `--parser=prism` https://bugs.ruby-lang.org/issues/20073 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following code works with both CRuby's compiler and Prism when evaluated using `RubyVM::InstructionSequence` ``` ~/git/ruby master ≡ ❯ ./miniruby -d -e'p RubyVM::InstructionSequence.compile_prism("tap { }").eval' main ~/git/ruby master ≡ ❯ ./miniruby -d -e'p RubyVM::InstructionSequence.compile("tap { }").eval' main ``` However when using the command line `--parser=prism` flag it results in a `NoMethodError` attempting to find `tap`, whereas CRuby's parser does not. ``` ~/git/ruby master ≡ ❯ ./miniruby -d -e'p tap { }' main ~/git/ruby master ≡ ❯ ./miniruby --parser=prism -d -e'p tap { }' ./miniruby: warning: The compiler based on the Prism parser is currently experimental and compatibility with the compiler based on parse.y is not yet complete. Please report any issues you find on the `ruby/prism` issue tracker. Exception `NoMethodError' at <compiled> - undefined method `tap' for main <compiled>:in `<compiled>': undefined method `tap' for main (NoMethodError) ``` This appears to be because the toplevel binding context is not being prepended to the linked list of instruction sequences when `--parser=prism` is passed. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115751] [Ruby master Bug#20067] IO.pipe `int_enc` and `ext_enc` not working as documented?
by byroot (Jean Boussier) 19 Dec '23

19 Dec '23

Issue #20067 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20067: IO.pipe `int_enc` and `ext_enc` not working as documented? https://bugs.ruby-lang.org/issues/20067 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- From the documentation: > pipe(ext_enc, int_enc, **opts) > If argument int_enc is given, it must be an Encoding object or encoding name string that specifies the internal encoding to be used; if argument ext_enc is also given, it must be an Encoding object or encoding name string that specifies the external encoding to be used. Test script: ```ruby ios = IO.pipe(Encoding::BINARY, Encoding::BINARY) p [:internal, *ios.map(&:internal_encoding)] p [:external, *ios.map(&:external_encoding)] Encoding.default_internal = Encoding::UTF_8 Encoding.default_external = Encoding::UTF_8 ios = IO.pipe(Encoding::BINARY, Encoding::BINARY) p [:internal, *ios.map(&:internal_encoding)] p [:external, *ios.map(&:external_encoding)] ``` Actual output: ``` [:internal, nil, nil] [:external, #<Encoding:ASCII-8BIT>, nil] [:internal, nil, nil] [:external, #<Encoding:ASCII-8BIT>, #<Encoding:UTF-8>] ``` Expected output: ``` [:internal, #<Encoding:ASCII-8BIT>, #<Encoding:ASCII-8BIT>] [:external, #<Encoding:ASCII-8BIT>, #<Encoding:ASCII-8BIT>] [:internal, #<Encoding:ASCII-8BIT>, #<Encoding:ASCII-8BIT>] [:external, #<Encoding:ASCII-8BIT>, #<Encoding:ASCII-8BIT>] ``` Am I reading the documentation incorrectly, or is it just not working as claimed? I tried on older versions, and it seems to have been like that all the way down to Ruby 1.9. The only reliable way I found to have a "binary" pipe is to call `IO#binmode`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111742] [Ruby master Feature#19326] Please add a better API for passing a Proc to a Ractor
by sdwolfz 19 Dec '23

19 Dec '23

Issue #19326 has been reported by sdwolfz (Codruț Gușoi). ---------------------------------------- Feature #19326: Please add a better API for passing a Proc to a Ractor https://bugs.ruby-lang.org/issues/19326 * Author: sdwolfz (Codruț Gușoi) * Status: Open * Priority: Normal ---------------------------------------- Example 1: ```ruby class Worker def initialize(&block) @block = block end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:271:in `new': allocator undefined for Proc (TypeError) from scripts/run.rb:9:in `run' from scripts/run.rb:14:in `<main>' ``` Example 2: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00007f00394c38b8 scripts/run.rb:13> (Ractor::IsolationError) from scripts/run.rb:5:in `initialize' from scripts/run.rb:13:in `new' from scripts/run.rb:13:in `<main>' ``` Example 3: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Ractor.current.instance_eval { Worker.new { 1 } } puts worker.run.take ``` Works, but having `Ractor.current.instance_eval` as a wrapper around the block is not ideal, as Ractor is supposed to be only an implementation detail in Worker. I know about https://bugs.ruby-lang.org/issues/18243 and the discussion around `proc.bind(nil)`. That would actually be ideal, as for the purposes if why I want this functionality I don't care what `self` is in a block, and the less it has access to the better. The general idea is to have a Ractor be able to lazily execute an arbitrary proc. And all the bindings it would need would be passed explicitly, either through `args` in the constructor or through `send`/`receive`, so `self` would really not matter. The benefit: this would make it so concurrent code can be more easily be implemented with Ractors as currently you can execute an arbitrary proc by passing it to a Thread (but you don't get the nice data isolation). -- https://bugs.ruby-lang.org/

5 9

[ruby-core:115328] [Ruby master Bug#19996] `RUBY_MN_THREADS=1` triggers Action Cable unit test failures
by yahonda (Yasuo Honda) 19 Dec '23

19 Dec '23

Issue #19996 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #19996: `RUBY_MN_THREADS=1` triggers Action Cable unit test failures https://bugs.ruby-lang.org/issues/19996 * Author: yahonda (Yasuo Honda) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-09T16:24:15Z :detached: c49adfab5d) +MN [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ### Steps to reproduce 1. Install `ruby 3.3.0dev` 2. Set `RUBY_MN_THREADS=1` environment variable 3. git clone https://github.com/rails/rails cd rails rm Gemfile.lock bundle install cd actioncable bin/test test/channel/base_test.rb test/subscription_adapter/redis_test.rb test/channel/test_case_test.rb test/subscription_adapter/redis_test.rb test/client_test.rb --seed 14800 ``` ### Expected behavior It should pass as not setting ``` $ unset RUBY_MN_THREADS $ bin/test test/channel/base_test.rb test/subscription_adapter/redis_test.rb test/channel/test_case_test.rb test/subscription_adapter/redis_test.rb test/client_test.rb --seed 14800 /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/minitest-5.20.0/lib/minitest.rb:3: warning: mutex_m which will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Run options: --seed 14800 # Running: ......................................................................... Finished in 12.031310s, 6.0675 runs/s, 46.7115 assertions/s. 73 runs, 562 assertions, 0 failures, 0 errors, 0 skips $ ``` ### Actual behavior It usually fails as follows. ``` $ bin/test test/channel/base_test.rb test/subscription_adapter/redis_test.rb test/channel/test_case_test.rb test/subscription_adapter/redis_test.rb test/client_test.rb --seed 14800 /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/minitest-5.20.0/lib/minitest.rb:3: warning: mutex_m which will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Run options: --seed 14800 # Running: ..................................................F Failure: RedisAdapterTest::AlternateConfiguration#test_channel_prefix [/home/yahonda/src/github.com/rails/rails/actioncable/test/subscription_adapter/common.rb:35]: Expected #<Concurrent::Event:0x00007f0b2698d4f0 @__Lock__=#<Thread::Mutex:0x00007f0b26f8cab8>, @__Condition__=#<Thread::ConditionVariable:0x00007f0b26f8ca90>, @set=false, @iteration=0> to be set?. bin/test test/subscription_adapter/channel_prefix.rb:6 .F Failure: RedisAdapterTest::AlternateConfiguration#test_multiple_broadcast [/home/yahonda/src/github.com/rails/rails/actioncable/test/subscription_adapter/common.rb:35]: Expected #<Concurrent::Event:0x00007f0b2698a4d0 @__Lock__=#<Thread::Mutex:0x00007f0b26fac688>, @__Condition__=#<Thread::ConditionVariable:0x00007f0b26fac4f8>, @set=false, @iteration=0> to be set?. bin/test test/subscription_adapter/common.rb:74 E Error: ClientTest#test_interacting_clients: ThreadError: queue empty <internal:thread_sync>:18:in `pop' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:168:in `read_message' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:241:in `block (2 levels) in test_interacting_clients' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:218:in `block (2 levels) in concurrently' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1583:in `evaluate_to' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1766:in `block in on_resolvable' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:352:in `run_task' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:343:in `block (3 levels) in create_worker' <internal:kernel>:187:in `loop' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:334:in `block (2 levels) in create_worker' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:333:in `catch' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:333:in `block in create_worker' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1258:in `raise' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1258:in `wait_until_resolved!' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:988:in `value!' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:218:in `map' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:218:in `concurrently' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:240:in `block in test_interacting_clients' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:90:in `with_puma_server' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:234:in `test_interacting_clients' bin/test test/client_test.rb:233 E Error: ClientTest#test_disappearing_client: ThreadError: queue empty <internal:thread_sync>:18:in `pop' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:168:in `read_message' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:275:in `block in test_disappearing_client' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:90:in `with_puma_server' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:273:in `test_disappearing_client' bin/test test/client_test.rb:272 .................. Finished in 1323.812615s, 0.0551 runs/s, 0.3830 assertions/s. 73 runs, 507 assertions, 2 failures, 2 errors, 0 skips $ ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115635] [Ruby master Bug#20045] `TestDir#test_home` fails on i686
by vo.x (Vit Ondruch) 19 Dec '23

19 Dec '23

Issue #20045 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20045: `TestDir#test_home` fails on i686 https://bugs.ruby-lang.org/issues/20045 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [i686-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This is followup to #19147. Testing on Fedora 38 and Fedora Rawhide, we are facing this test failure: ~~~ $ tar xf build/SOURCES/ruby-3.2.2.tar.xz $ cd ruby-3.2.2/ $ ./configure && make ... snip ... --- Configuration summary for ruby version 3.2.2 * Installation prefix: /usr/local * exec prefix: ${prefix} * arch: i686-linux * site arch: ${arch} * RUBY_BASE_NAME: ruby * ruby lib prefix: ${libdir}/${RUBY_BASE_NAME} * site libraries path: ${rubylibprefix}/${sitearch} * vendor path: ${rubylibprefix}/vendor_ruby * target OS: linux * compiler: gcc * with thread: pthread * with coroutine: x86 * enable shared libs: no * dynamic library ext: so * CFLAGS: ${optflags} ${debugflags} ${warnflags} * LDFLAGS: -L. -fstack-protector-strong -rdynamic -Wl,-export-dynamic * DLDFLAGS: -Wl,--compress-debug-sections=zlib * optflags: -O3 -fno-fast-math * debugflags: -ggdb3 * warnflags: -Wall -Wextra -Wdeprecated-declarations -Wdiv-by-zero -Wduplicated-cond -Wimplicit-function-declaration -Wimplicit-int -Wmisleading-indentation -Wpointer-arith -Wwrite-strings -Wold-style-definition \ -Wimplicit-fallthrough=0 -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-packed-bitfield-compat \ -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wunused-variable -Wundef * strip command: strip -S -x * install doc: rdoc * MJIT support: yes * YJIT support: no * man page type: doc --- ... snip ... $ LANG=C make test-all 'TESTS=-v -n /TestDir#test_home/' config.status: creating ruby-runner.h making mjit_build_dir.so generating i686-linux-fake.rb i686-linux-fake.rb updated Run options: --seed=10517 "--ruby=./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=./test/excludes --name=!/memory_leak/ -v -n /TestDir#test_home/ # Running tests: [1/0] TestDir#test_home = 0.00 s 1) Error: TestDir#test_home: RuntimeError: can't set length of shared string /builddir/ruby-3.2.2/test/ruby/test_dir.rb:557:in `expand_path' /builddir/ruby-3.2.2/test/ruby/test_dir.rb:557:in `block in test_home' Finished tests in 4.164691s, 0.2401 tests/s, 1.6808 assertions/s. 1 tests, 7 assertions, 0 failures, 1 errors, 0 skips ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [i686-linux] make: *** [uncommon.mk:855: yes-test-all] Error 1 ~~~ Please note that having the `C` locale is essential. The test passes just fine with e.g. `C.UTF-8` locale. We were able to reduce the test case to the following: ~~~ $ whoami mockbuild $ echo 'File.expand_path("~mockbuild")' > test.rb $ LANG=C RUBYLIB=/builddir/ruby-3.2.2/.ext/i686-linux LD_LIBRARY_PATH=. ./ruby --disable-gems test.rb test.rb:1:in `expand_path': can't set length of shared string (RuntimeError) from test.rb:1:in `<main>' ~~~ As I said earlier, the `LANG=C` is essential as well as the `RUBYLIB=/builddir/ruby-3.2.2/.ext/i386-linux`. Adding the path to `RUBYLIB` enables Ruby to load the following libraries: ~~~ /builddir/ruby-3.2.2/.ext/i686-linux/enc/encdb.so /builddir/ruby-3.2.2/.ext/i686-linux/enc/trans/transdb.so ~~~ And that makes the difference. Also, the `File.expand_path("~mockbuild")` must be in some file, replacing this by `-e 'File.expand_path("~mockbuild")'` does not reproduce the issue. We also believe that this was introduced by https://github.com/ruby/ruby/pull/6699, specifically by commit:git|5246f4027ec574e77809845e1b1f7822cc2a5cef and fixed in master by commit:git|b4571097df4a6bd848f1195026d82a92f3a7f9d8. Unfortunately, we were not able to discover what is the mechanism behind this, why this depends on locale, why the test must be in file, why the string is shared etc. But I hope we have provided enough details for someone else more knowledgeable. Some background for this issue is also available here: https://src.fedoraproject.org/rpms/ruby/pull-request/164 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115744] [Ruby master Bug#20065] cannot require "net/smtp" with Ruby3.3.0-rc1 and bundler 2.5.0.dev
by s3fxn (s3 fxn) 19 Dec '23

19 Dec '23

Issue #20065 has been reported by s3fxn (s3 fxn). ---------------------------------------- Bug #20065: cannot require "net/smtp" with Ruby3.3.0-rc1 and bundler 2.5.0.dev https://bugs.ruby-lang.org/issues/20065 * Author: s3fxn (s3 fxn) * Status: Open * Priority: Normal * ruby -v: 3.3.0-rc1 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- $ ruby -v ruby 3.3.0rc1 (2023-12-11 master a49643340e) [x86_64-linux] $ bundle -v Bundler version 2.5.0.dev $ bundle init $ bundle add net-smtp $ bundle exec ruby -e 'require "net/smtp"' -e:1: warning: net/smtp was loaded from the standard library, but is not part of the default gems since Ruby 3.1.0. Add net-smtp to your Gemfile or gemspec. $ tail -1 Gemfile gem "net-smtp", "~> 0.4.0" -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115598] [Ruby master Bug#20044] Add runtime flag and environment variable for prism
by HParker (Adam Hess) 19 Dec '23

19 Dec '23

Issue #20044 has been reported by HParker (Adam Hess). ---------------------------------------- Bug #20044: Add runtime flag and environment variable for prism https://bugs.ruby-lang.org/issues/20044 * Author: HParker (Adam Hess) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- To enable prism to be used as the parser when running Ruby code, I would like to add a runtime flag and environment variable that allow it to be enabled. The flags could be, ``` ruby --prism test.rb ``` and the environment variable could be, ``` RUBY_PRISM=1 ruby test.rb ``` Previously implemented here: https://github.com/ruby/ruby/pull/9115, but merged before discussion could happen. Things to be sure to discuss mentioned by @mame, > * What to do with the command-line option when prism becomes the default parser in the future. > ** Just remove it, or leave it as a "do nothing" option? > * What are the appropriate names. > ** In Ruby, not absolutely but the names of features for professional use tend to be long and verbose, while those used by ordinary users tend to be short. > * Whether to print a warning when this mode is used. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:115644] [Ruby master Misc#20046] DevMeeting-2023-12-20
by mame (Yusuke Endoh) 18 Dec '23

18 Dec '23

Issue #20046 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #20046: DevMeeting-2023-12-20 https://bugs.ruby-lang.org/issues/20046 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/12/20 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2023/12/17. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115776] [Ruby master Bug#20071] Reading code from stdin SEGV's when `--parser=prism`
by eightbitraptor (Matthew Valentine-House) 18 Dec '23

18 Dec '23

Issue #20071 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Bug #20071: Reading code from stdin SEGV's when `--parser=prism` https://bugs.ruby-lang.org/issues/20071 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following examples all SEGV on master. ``` ruby --parser=prism cat test_code.rb | ruby --parser=prism ruby --parser=prism < test_code.rb ``` This is because the prism setup code in `process_options` either assumes that a file has been passed or an explicit string with `-e` and does not handle the case where the input is expected to come from `stdin`. [This PR attempts to address this](https://github.com/ruby/ruby/pull/9282) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:115772] [Ruby master Feature#20070] commas in pattern match
by Dan0042 (Daniel DeLorme) 18 Dec '23

18 Dec '23

Issue #20070 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20070: commas in pattern match https://bugs.ruby-lang.org/issues/20070 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- In pattern matching, `case v; in 1,2,3` is a synonym for `case v; in [1,2,3]` This is the one thing that keeps confusing me, that I haven't been able to get used to. Because I'm used to `case v; when 1,2,3` it feels like `case v; in 1,2,3` should have a similar meaning. So it's possible to omit the square brackets but honestly I don't see much point for that, it just makes it look to me like something it is not. In other words, I feel it would be far more intuitive (at least to me) if ```ruby case v in 1,2,3 ``` was a synonym for ```ruby case v in 1 in 2 in 3 ``` or possibly a synonym for ```ruby case v in (1|2|3) ``` which would make it similar to the syntax in `rescue A, B, C => err` Is it too late to change this? -- https://bugs.ruby-lang.org/

2 3