November 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:119335] [Ruby master Bug#20770] A *new* pipe operator proposal
by AlexandreMagro (Alexandre Magro) 05 Jan '25

05 Jan '25

Issue #20770 has been reported by AlexandreMagro (Alexandre Magro). ---------------------------------------- Bug #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770 * Author: AlexandreMagro (Alexandre Magro) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hello, This is my first contribution here. I have seen previous discussions around introducing a pipe operator, but it seems the community didn't reach a consensus. I would like to revisit this idea with a simpler approach, more of a syntactic sugar that aligns with how other languages implement the pipe operator, but without making significant changes to Ruby's syntax. Currently, we often write code like this: ```ruby value = half(square(add(value, 3))) ``` We can achieve the same result using the `then` method: ```ruby value = value.then { add(_1, 3) }.then { square(_1) }.then { half(_1) } ``` While `then` helps with readability, we can simplify it further using the proposed pipe operator: ```ruby value = add(value, 3) |> square(_1) |> half(_1) ``` Moreover, with the upcoming `it` feature in Ruby 3.4 (#18980), the code could look even cleaner: ```ruby value = add(value, 3) |> square(it) |> half(it) ``` This proposal uses the anonymous block argument `(_1)`, and with `it`, it simplifies the code without introducing complex syntax changes. It would allow us to achieve the same results as in other languages that support pipe operators, but in a way that feels natural to Ruby, using existing constructs like `then` underneath. I believe this operator would enhance code readability and maintainability, especially in cases where multiple operations are chained together. Thank you for considering this proposal! -- https://bugs.ruby-lang.org/

18 55

[ruby-core:111450] [Ruby master Bug#19268] Mingw64 Build Failure
by cfis (Charlie Savage) 31 Dec '24

31 Dec '24

Issue #19268 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #19268: Mingw64 Build Failure https://bugs.ruby-lang.org/issues/19268 * Author: cfis (Charlie Savage) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x64-mingw-ucrt] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- For both Ruby 3.1.3 and Ruby 3.2.0, building on msys2/ucrt64 fails: ``` c linking miniruby.exe /usr/bin/sh: -c: line 1: syntax error near unexpected token `(' /usr/bin/sh: -c: line 1: `/usr/local/ruby/bin/ruby --disable=gems -n -e BEGIN{version=ARGV.shift;mis=ARGV.dup} -e END{abort "UNICODE version mismatch: #{mis}" unless mis.empty?} -e (mis.delete(ARGF.path); ARGF.close) if /ONIG_UNICODE_VERSION_STRING +"#{Regexp.quote(version)}"/o 15.0.0 ./enc/unicode/15.0.0/casefold.h ./enc/unicode/15.0.0/name2ctype.h' make: *** [uncommon.mk:878: .rbconfig.time] Error 2 ``` The fix that works for me is changing: ``` c -e '(mis.delete(ARGF.path); ARGF.close) if /ONIG_UNICODE_VERSION_STRING +"#{Regexp.quote(version)}"/o' \ ``` To ``` c -e "(mis.delete(ARGF.path); ARGF.close) if /ONIG_UNICODE_VERSION_STRING +\"#{Regexp.quote(version)}\"/o" \ ``` ``` -- https://bugs.ruby-lang.org/

1 4

[ruby-core:116009] [Ruby master Bug#20147] FreeBSD libyaml
by kaiquekandykoga 31 Dec '24

31 Dec '24

Issue #20147 has been reported by kaiquekandykoga (Kaíque Koga). ---------------------------------------- Bug #20147: FreeBSD libyaml https://bugs.ruby-lang.org/issues/20147 * Author: kaiquekandykoga (Kaíque Koga) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I use ruby-install to manage multiple Ruby versions. Some time ago I had issues installing Ruby 3.2.2 https://github.com/postmodern/ruby-install/issues/463, and the same issue was open for ruby-build in https://github.com/rbenv/ruby-build/issues/2184. I am trying to install Ruby 3.3.0 using ruby-install, and the same behaviour is occurring. Please, take a look in the links I have provided for detailed information. ``` shell /usr/home/kandy/src/ruby-3.3.0/lib/yaml.rb:3: warning: It seems your ruby installation is missing psych (for YAML output). To eliminate this warning, please install libyaml and reinstall your ruby. uh-oh! RDoc had a problem: cannot load such file -- psych run with --debug for full backtrace *** Error code 1 Stop. make: stopped in /usr/home/kandy/src/ruby-3.3.0 !!! Compiling ruby 3.3.0 failed! ``` Thank you. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:119534] [Ruby master Bug#20800] Don't place `ruby` executable into `/usr/libexec/x86_64-linux/bin`
by vo.x (Vit Ondruch) 27 Dec '24

27 Dec '24

Issue #20800 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20800: Don't place `ruby` executable into `/usr/libexec/x86_64-linux/bin` https://bugs.ruby-lang.org/issues/20800 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.4.0dev (2024-10-15 master 3da3cabf98) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Trying to prepare Ruby 3.4 package for Fedora, it seems that since [1], the `ruby` executable is installed into `/usr/libexec/x86_64-linux/bin`: ~~~ installing binary commands: /usr/libexec/x86_64-linux/bin ~~~ Unfortunately, the PR does not explain anything about reasons why. To me, using `libexec` is surprising, because according to FHS [2], the directory is for internal binaries. What is even more surprising is usage of the `bin` subdirectory there, which IMHO does not follow any standard or convention (I don't have `/usr/libexec/x86_64-linux/bin` directory on my Fedora yet). Just FTR, these are the configuration options used: ~~~ /builddir/build/BUILD/ruby-3.4.0_20241016git3da3cabf98-build/ruby-3.4.0-3da3cabf98/configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-rubylibprefix=/usr/share/ruby --with-archlibdir=/usr/lib64 --with-rubyarchprefix=/usr/lib64/ruby --with-sitedir=/usr/local/share/ruby/site_ruby --with-sitearchdir=/usr/local/lib64/ruby/site_ruby --with-vendordir=/usr/share/ruby/vendor_ruby --with-vendorarchdir=/usr/lib64/ruby/vendor_ruby --with-rubyhdrdir=/usr/include --with-rubyarchhdrdir=/usr/include '--with-sitearchhdrdir=$(sitehdrdir)/$(arch)' '--with-vendorarchhdrdir=$(vendorhdrdir)/$(arch)' --with-rubygemsdir=/usr/share/rubygems --with-ruby-pc=ruby.pc --with-compress-debug-sections=no --disable-rpath --enable-mkmf-verbose --enable-shared --with-ruby-version= --enable-multiarch --enable-yjit ~~~ The `--enable-multiarch` is among the options. It is used not because Fedora would be `multiarch`, but because it provides the highest flexibility. [1]: https://github.com/ruby/ruby/pull/10010 [2]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html -- https://bugs.ruby-lang.org/

4 9

[ruby-core:118182] [Ruby master Bug#20526] File.open(encoding: "bom|utf-8") converts "\r\n" to "\n" on Windows
by kou (Kouhei Sutou) 26 Dec '24

26 Dec '24

Issue #20526 has been reported by kou (Kouhei Sutou). ---------------------------------------- Bug #20526: File.open(encoding: "bom|utf-8") converts "\r\n" to "\n" on Windows https://bugs.ruby-lang.org/issues/20526 * Author: kou (Kouhei Sutou) * Status: Open * Target version: 3.2 * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I'm not sure whether this is an intentional behavior but it seems that `encoding: "utf-8"` doesn't change newline conversion but `encoding: "bom|utf-8"` changes newline conversion: ```ruby File.write("a.txt", "a\r\n") File.read("a.txt").bytes # => [97, 13, 10] File.open("a.txt", encoding: "utf-8") {|f| f.read.bytes} # => [97, 10, 10] File.open("a.txt", encoding: "bom|utf-8") {|f| f.read.bytes} # => [97, 10] XXX: \r\n -> \n File.open("a.txt", encoding: "bom|utf-8", universal_newline: false) {|f| f.read.bytes} # => [97, 13, 10] ``` Note that the `XXX: ` line the above codes. Is this an intentional behavior? -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119881] [Ruby master Feature#20884] reserve "Ruby" toplevel module for Ruby language
by Dan0042 (Daniel DeLorme) 25 Dec '24

25 Dec '24

Issue #20884 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20884: reserve "Ruby" toplevel module for Ruby language https://bugs.ruby-lang.org/issues/20884 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- `Ruby` would be a convenient namespace for many features of the Ruby language, in particular APIs related to the interpreter. All these constants: RUBY_VERSION RUBY_RELEASE_DATE RUBY_PLATFORM RUBY_PATCHLEVEL RUBY_REVISION RUBY_COPYRIGHT RUBY_ENGINE RUBY_ENGINE_VERSION RUBY_DESCRIPTION would have made a lot of sense as `Ruby::Version` etc. `Thread::Backtrace::Location` would have made a lot of sense as `Ruby::Backtrace::Location` `RubyVM` is considered specific to CRuby; so `RubyVM::AbstractSyntaxTree` should be `Ruby::AbstractSyntaxTree` if it is meant to be present in other implementations. In #6648 there's a bit of contention over where `ruby_args` should be. `RubyVM`, `RbConfig`, `Process` have all been proposed, but `Ruby` would be an excellent choice. `Process.argv0` was added in Ruby 2.1 but the `Process` namespace is really about OS-level process control (fork, signals, euid, limits) while this argv0 is not (in `ps` it's neither value of COMMAND nor CMD) so it would have made sense as `Ruby.argv0` The "ruby" gem name is reserved, so there's no conflict. https://rubygems.org/gems/ruby All in all, "Ruby" is an appropriate namespace for many Ruby things. We don't want to break compatibility over this, but we could at least start small by reserving the namespace, and see how it grows from there. module Ruby Version = ::RUBY_VERSION end -- https://bugs.ruby-lang.org/

7 7

[ruby-core:118243] [Ruby master Feature#20564] Switch default parser to Prism
by kddnewton (Kevin Newton) 24 Dec '24

24 Dec '24

Issue #20564 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #20564: Switch default parser to Prism https://bugs.ruby-lang.org/issues/20564 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- This issue is to propose switching the default parser for Ruby to Prism on the master branch. The main goal is to get this default into both master and the next preview so that the community has plenty of time to test before the eventual 3.4 release. Matz has indicated that the final decision about the default parser for Ruby 3.4 will be made later in the year. Decisions about the default parser for Ruby 3.5+ and the relationship between Prism, lrama, parse.y, etc. will also be made at a later time. ## Background For some background on the Prism project itself, here are a couple of links in chronological order that you can read: * https://bugs.ruby-lang.org/issues/19741 * https://railsatscale.com/2023-06-12-rewriting-the-ruby-parser/ * https://kddnewton.com/2024/01/23/prism.html * https://railsatscale.com/2024-04-16-prism-in-2024/ ## Status Prism now passes all Ruby tests and specs. Internally at Shopify, it also passes our Core monolith's CI, which is a large and complex Rails application. We are confident that it is ready for production use. External to CRuby, Prism has already been adopted extensively around the ecosystem, including but not limited to: * [JRuby](https://github.com/jruby/jruby/pull/8103) (via Java) * [TruffleRuby](https://github.com/oracle/truffleruby/issues/3117) (via Java) * [Natalie](https://github.com/natalie-lang/natalie/pull/1213) (via C++ and Ruby) * [Opal](https://github.com/opal/opal/pull/2642) (via Ruby and WASM) * [repl_type_completor](https://github.com/ruby/repl_type_completor) * [rubocop](https://docs.rubocop.org/rubocop/configuration.html#setting-the-pa… (via parser translator) * [ruby-lsp](https://github.com/Shopify/ruby-lsp) * [packwerk](https://github.com/Shopify/packwerk/pull/388) (via parser translator) Fortunately with the community adoption, we have been able to find many edge cases and bugs that have been fixed. Thank you so much to everyone who has tried, used, reported problems with, and improved Prism in the last couple of years. We would not have hit this milestone without this community involvement. ## Caveats While Prism correctly accepts and parses all valid Ruby syntax, there are still a number of cases where it does not reject invalid syntax as it should. We are currently working on these cases, and we are confident that we can eliminate them before the next preview release. You can find them listed here: https://github.com/ruby/prism/issues?q=is%3Aopen+is%3Aissue+label%3Ainvalid…. This is our top priority right now, and I anticipate these being resolved quickly. The other caveat is unknown unknowns: bugs or syntax issues that we have yet to discover. At Shopify we are currently taking numerous steps to mitigate this risk, including: * Prism currently passes all Ruby tests and specs, and will continue to going forward. The tests and specs are extensive, and we are confident this gets us almost all of the way there. * Grammar-based fuzzing to ensure we handle all possible syntax variations (both valid and invalid). As an example, that recently led to the discovery that the current compiler was segfaulting on safe navigation in for loops (https://bugs.ruby-lang.org/issues/20468) It has also found several memory leaks that have been fixed. * Mutation testing of existing source files (by adding and deleting random bytes) to find additional edge cases. Our goal is 100% compatibility, and we believe this is achievable through the above techniques and others. The goal of this proposal is to allow more companies to test their codebase against Prism, and to make this easier. We believe that we can sort out the remaining problems much more quickly in that manner. ## Implementation The implementation will be relatively straightforward, as there is already the `--parser` flag that can be used to switch between the current parser and Prism. We will change the default to be `"prism"` instead of `"parse.y"`. There is no plan to remove or change any code related to `parse.y`, `lrama`, or `compile.c` at this time, as we want to create the minimal amount of change possible to ensure stability. -- https://bugs.ruby-lang.org/

4 9

[ruby-core:119413] [Ruby master Bug#20779] Un-rescuable thread creation limit on Mac
by hms (Hal Spitz) 23 Dec '24

23 Dec '24

Issue #20779 has been reported by hms (Hal Spitz). ---------------------------------------- Bug #20779: Un-rescuable thread creation limit on Mac https://bugs.ruby-lang.org/issues/20779 * Author: hms (Hal Spitz) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Thread.new will hang the ruby process once past the OSX limit. It does not appear that's possible to trap and rescue failed thread creation. It seems the Mac has a limit to the number of threads it supports and googling the issue suggests the limit has been known to change with hardware and OS releases. While I hit the thread creation limit due to a bug in my code and the number of threads that I was attempting to create (12,250+) is an unlikely use-case, I am hoping it would be possible to turn this into a rescuable error. While I'm reporting this on 3.3.5, I have tested the issue and the inability to rescue back to 3.3.1. (Thanks to @raels for being a great second set of eyes to make sure I wasn't doing anything goofy / wrong before making this report. Also, another callout and thanks to both @eregon and @bensheldon over at concurrent-ruby for the unbelievably quick and helpful response to my initial bug report over there). ---Files-------------------------------- hang.rb (713 Bytes) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117812] [Ruby master Bug#20478] Circular parameter syntax error rules
by kddnewton (Kevin Newton) 20 Dec '24

20 Dec '24

Issue #20478 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20478: Circular parameter syntax error rules https://bugs.ruby-lang.org/issues/20478 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I would like to revisit https://bugs.ruby-lang.org/issues/16343. These cases are syntax errors: ```ruby def foo(bar = -> { bar }) end # no lambda parameters def foo(bar = ->() { bar }) end # no lambda parameters def foo(bar = baz { bar }) end # no block parameters def foo(bar = baz { _1 + bar }) end # parameters, but no pipes def foo(bar = baz { it + bar }) end # parameters, but no pipes ``` These cases are not syntax errors: ```ruby def foo(bar = ->(baz) { bar }) end # lambda parameters def foo(bar = baz { || bar }) end # no block parameters but empty pipes def foo(bar = baz { |qux| bar }) end # block parameters ``` I don't think these rules are very intuitive, and they feel somewhat arbitrary. I would like to suggest we change them to be either: * Syntax error is raised if the parameter is ever read in its default value at any scope depth * Syntax error is raised if the parameter is ever read in its default value at depth 0 Either one is fine by me, but gating the syntax error based on the presence of pipes is really confusing. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:119883] [Ruby master Feature#20885] String#gsub?
by Dan0042 (Daniel DeLorme) 18 Dec '24

18 Dec '24

Issue #20885 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20885: String#gsub? https://bugs.ruby-lang.org/issues/20885 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- I would like a variation of sub/gsub that returns a new string if there is a match, or nil otherwise. This can be currently done with `str.dup.gsub!(...)` at the mere cost of 2 unnecessary extra allocations due to String#dup TBH I'm not sure we need yet another gsub method, but what gets me here is that `gsub?` is the primitive operation from which `gsub` and `gsub!` are made. Internally, these two methods work like this: ```ruby def gsub!(...) modified = gsub?(...) and replace(modified) end def gsub(...) gsub?(...) or dup end ``` We can efficiently derive these two methods from `gsub?`, but we cannot efficiently implement `gsub?` in ruby, so it feels regrettable to me that `gsub?` is not available as a built-in. Use cases include: ```ruby #ensure gsub has modified the string newstr = str.gsub?(rx,repl) or raise "str did not contain expected value" #take an action if the string is modified if str = obj.title.gsub?(rx,repl) obj.title = str obj.save end ``` -- https://bugs.ruby-lang.org/

2 2