September 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:117618] [Ruby master Feature#20437] Could be the licensing conditions be made less ambiguous?
by vo.x (Vit Ondruch) 03 Jan '25

03 Jan '25

Issue #20437 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Feature #20437: Could be the licensing conditions be made less ambiguous? https://bugs.ruby-lang.org/issues/20437 * Author: vo.x (Vit Ondruch) * Status: Open ---------------------------------------- # Current state The current [COPYING](https://github.com/ruby/ruby/blob/6cfd929034f1fe3d93160365505a8b88… file says the following: ~~~ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the 2-clause BSDL (see the file BSDL), or the conditions below: 1. You may make and give away verbatim copies of the source form of the ... snip ... ~~~ And this is quite ambiguous. Let me show a few examples: # Ambiguous examples ## lib/net/protocol.rb https://github.com/ruby/ruby/blob/6cfd929034f1fe3d93160365505a8b88bef56159/… ~~~ # This program is free software. You can re-distribute and/or # modify this program under the same terms as Ruby itself, # Ruby Distribute License or GNU General Public License. ~~~ So what is the license? Is it 2-clause BSDL + Ruby + GPL? Or is is just Ruby + GPL but not 2-clause BSDL? ## Racc https://github.com/ruby/racc/blob/d52fb64d166046bfde81e6e9c424fcd884ebcabf/… ~~~ Racc is distributed under the same terms of ruby. (see the file COPYING). ~~~ where the [COPYING](https://github.com/ruby/racc/blob/d52fb64d166046bfde81e6e9c424fcd8… contains just 2-clause BSDL. Not even mentioning that Ruby used to be GPLv2 licensed: https://github.com/ruby/racc/commit/cc7fe952a6b1fc2ef43477674fa13f2d9d99e818 ## Rubygems https://github.com/rubygems/rubygems/blob/master/LICENSE.txt The license is obviously modeled after Ruby COPYING file, but if it could say "licensed under MIT or Ruby", it would be much better. ## Gettext https://github.com/ruby-gettext/gettext/blob/8d84132efd888e68fffbce41331645… The license note is so old that it is not obvious what that means and what was the intention. Did the Ruby relicensing from "GPLv2 or Ruby" to "GPLv2 or BSD" influenced this project? ## SPDX https://spdx.org/licenses/Ruby.html It quotes just the "conditions below" as a Ruby license, while referring to [Ruby license file](https://www.ruby-lang.org/en/about/license.txt) mentioning also 2-clause BSDL # Proposal To me it seems that the whole world recognizes "Ruby" license, except Ruby. Therefore I think it would be nice if Ruby project recognized the "Ruby" license. There are two possibilities I can think of: ## Refer the license by name ~~~diff $ git diff diff --git a/COPYING b/COPYING index 48e5a96de7..a2d179a8a9 100644 --- a/COPYING +++ b/COPYING @@ -1,6 +1,6 @@ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the -2-clause BSDL (see the file BSDL), or the conditions below: +2-clause BSDL (see the file BSDL), or the conditions of the Ruby license below: 1. You may make and give away verbatim copies of the source form of the software without restriction, provided that you duplicate all of the ~~~ ## Extract the "conditions below" into "Ruby" license file The "conditions below" text could be extracted into separate file (e.g. "RUBY_LICENSE") and the "COPYING" file rephrased to say: ~~~ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the 2-clause BSDL (see the file BSDL), or Ruby license (see the file RUBY_LICENSE) ~~~ -- https://bugs.ruby-lang.org/

2 4

[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: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: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:115438] [Ruby master Misc#20013] Travis CI status
by jaruga (Jun Aruga) 23 Dec '24

23 Dec '24

Issue #20013 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #20013: Travis CI status https://bugs.ruby-lang.org/issues/20013 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal ---------------------------------------- I would like to use this ticket to manage our activities to report Travis CI status. Because there is Travis CI status page provided by Travis CI. However, even when the page shows ok, I actually see infra issues. https://www.traviscistatus.com/ I would share my activities and report the Travis CI status on the ticket. The ticket's status is not closed until we stop using Travis CI. The easiest option to fix the Travis infra issue is to email Travis CI support `support _AT_ travis-ci.com`. You can check [this ruby/ruby Travis CI wiki page](https://github.com/ruby/ruby/wiki/CI-Servers#travis-ci) for details. -- https://bugs.ruby-lang.org/

2 49

[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:118957] [Ruby master Bug#20699] On Windows, the `__dir__` keyword is garbled in paths containing Japanese characters, and `require_relative` fails as well
by flatland001 (Hayato Arai) 18 Dec '24

18 Dec '24

Issue #20699 has been reported by flatland001 (Hayato Arai). ---------------------------------------- Bug #20699: On Windows, the `__dir__` keyword is garbled in paths containing Japanese characters, and `require_relative` fails as well https://bugs.ruby-lang.org/issues/20699 * Author: flatland001 (Hayato Arai) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x64-mingw-ucrt] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In paths containing Japanese characters, such as: C:\テスト_test\test.rb Code: ``` ruby # this code -> C:\テスト_test\test.rb # external file -> C:\テスト_test\lib\foo.rb p __dir__ p __dir__.encoding p File.dirname(File.expand_path(__FILE__)) p File.dirname(File.expand_path(__FILE__)).encoding print "__dir__ == File.dirname(File.expand_path(__FILE__)): " p __dir__ == File.dirname(File.expand_path(__FILE__)) begin require_relative "lib/foo" puts "foo.rb loaded" rescue LoadError puts "LoadError: #{$!}" end ``` Results: ``` "C:/?e?X?g_test" #<Encoding:Windows-31J> "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> __dir__ == File.dirname(File.expand_path(__FILE__)): false LoadError: cannot load such file -- C:/?e?X?g_test/lib/foo ``` However, in ruby 3.2.5 (2024-07-26 revision 31d0f1a2e7) [x64-mingw-ucrt], the same code produces the following expected results: ``` "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> __dir__ == File.dirname(File.expand_path(__FILE__)): true foo.rb loaded ``` Is this behavior expected, or could this be a bug in the Ruby interpreter on Windows? If this is my misunderstanding or a known issue, I apologize. Thank you for your consideration. Environment Information: - OS: Windows 11 Pro 23H2 (OS build 22631.4037) - Installed via: RubyInstaller - Shell: Command Prompt - File System: NTFS - System Locale: Japanese (Japan), Language: Japanese -- https://bugs.ruby-lang.org/

3 2

[ruby-core:117657] [Ruby master Bug#20447] Ruby 3.3.1 broken on i686
by vo.x (Vit Ondruch) 15 Dec '24

15 Dec '24

Issue #20447 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20447: Ruby 3.3.1 broken on i686 https://bugs.ruby-lang.org/issues/20447 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [i686-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ~~~ gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fPIC -m32 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/i386-linux -I/builddir/build/BUILD/ruby-3.3.1/include -I/builddir/build/BUILD/ruby-3.3.1 -I/builddir/build/BUILD/ruby-3.3.1/prism -I/builddir/build/BUILD/ruby-3.3.1/enc/unicode/15.0.0 -o time.o -c /builddir/build/BUILD/ruby-3.3.1/time.c make: Leaving directory '/builddir/build/BUILD/ruby-3.3.1/redhat-linux-build' /builddir/build/BUILD/ruby-3.3.1/time.c: In function ‘zone_timelocal’: /builddir/build/BUILD/ruby-3.3.1/time.c:2345:35: error: passing argument 3 of ‘split_second’ from incompatible pointer type [-Wincompatible-pointer-types] 2345 | split_second(tobj->timew, &t, &s); | ^~ | | | wideval_t * {aka long long unsigned int *} /builddir/build/BUILD/ruby-3.3.1/time.c:616:58: note: expected ‘VALUE *’ {aka ‘long unsigned int *’} but argument is of type ‘wideval_t *’ {aka ‘long long unsigned int *’} 616 | split_second(wideval_t timew, wideval_t *timew_p, VALUE *subsecx_p) | ~~~~~~~^~~~~~~~~ make: *** [Makefile:447: time.o] Error 1 make: *** Waiting for unfinished jobs.... make: Entering directory '/builddir/build/BUILD/ruby-3.3.1/redhat-linux-build' ~~~ This is presumably due to #20327 / https://github.com/ruby/ruby/pull/10332. There seems to be medicine in master commit:git|055613fd868a8c94e43893f8c58a00cdd2a81f6d or maybe the whole https://github.com/ruby/ruby/pull/10332, not sure -- https://bugs.ruby-lang.org/

8 14