September 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:111988] [Ruby master Feature#19370] Anonymous parameters for blocks?
by zverok (Victor Shepelev) 23 Dec '23

23 Dec '23

Issue #19370 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19370: Anonymous parameters for blocks? https://bugs.ruby-lang.org/issues/19370 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- Just to clarify: are anonymous parameters delegation is planned to support in blocks? It would be a nice addition, if it is possible to implement: ```ruby # data in form [request method, URL, params]: [ [:get, 'https://google.com', {q: 'Ruby'}, {'User-Argent': 'Google-Chrome'}], [:post, 'https://gist.github.com', 'body'], # ... ].each { |method, *| request(method.to_s.upcase, *) } ``` ...and at the very least, consistent with what the method definition can have. If they are NOT planned to be implemented, I believe that at least error messages should be made much clearer, because currently, this would happen while running the code above: > no anonymous rest parameter (SyntaxError) I understand the reason (the `request` clause doesn't "see" anonymous parameter of the **block**, and claims that current **method** doesn't have them), but it looks honestly confusing and inconsistent. -- https://bugs.ruby-lang.org/

5 9

[ruby-core:112262] [Ruby master Feature#19422] Make `--enabled-shared` mandatory on macOS
by nobu (Nobuyoshi Nakada) 20 Dec '23

20 Dec '23

Issue #19422 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #19422: Make `--enabled-shared` mandatory on macOS https://bugs.ruby-lang.org/issues/19422 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal ---------------------------------------- From the troubles around linker on macOS, I propose `--enable-shared` option mandatory on macOS. This patch enables the option by default, and abort if `--disable-shared` option is given explicitly. ```diff diff --git i/configure.ac w/configure.ac index 7db2ab5257c..923ac7d1199 100644 --- i/configure.ac +++ w/configure.ac @@ -504,6 +504,11 @@ AS_CASE(["$target_os"], rb_cv_binary_elf=no : ${enable_shared=yes} ], +[darwin*], [ + AS_IF([test "${enable_shared=yes}" = no], [ + AC_MSG_ERROR([--disable-shared is not supported on this platform]) + ]) +], [hiuxmpp*], [AC_DEFINE(__HIUX_MPP__)]) # by TOYODA Eizi <toyoda(a)npd.kishou.go.jp> AC_PROG_LN_S @@ -3055,14 +3060,7 @@ AC_SUBST(EXTOBJS) : ${LDFLAGS=""} : ${LIBPATHENV=DYLD_FALLBACK_LIBRARY_PATH} : ${PRELOADENV=DYLD_INSERT_LIBRARIES} - AS_IF([test x"$enable_shared" = xyes], [ - # Resolve symbols from libruby.dylib when --enable-shared - EXTDLDFLAGS='$(LIBRUBYARG_SHARED)' - ], [test "x$EXTSTATIC" = x], [ - # When building exts as bundles, a mach-o bundle needs to know its loader - # program to bind symbols from the ruby executable - EXTDLDFLAGS="-bundle_loader '\$(BUILTRUBY)'" - ]) + EXTDLDFLAGS='$(LIBRUBYARG_SHARED)' rb_cv_dlopen=yes], [aix*], [ : ${LDSHARED='$(CC)'} AS_IF([test "$GCC" = yes], [ @@ -3356,10 +3354,6 @@ AS_IF([test x"$cross_compiling" = xyes], [ AC_SUBST(XRUBY_RUBYLIBDIR) AC_SUBST(XRUBY_RUBYHDRDIR) PREP='$(arch)-fake.rb' - AS_CASE(["$enable_shared:$EXTSTATIC:$target_os"], [no::darwin*], [ - # darwin target requires miniruby for linking ext bundles - PREP="$PREP"' miniruby$(EXEEXT)' - ]) RUNRUBY_COMMAND='$(MINIRUBY) -I`cd $(srcdir)/lib; pwd`' RUNRUBY='$(RUNRUBY_COMMAND)' XRUBY='$(MINIRUBY)' ``` -- https://bugs.ruby-lang.org/

4 7

[ruby-core:113572] [Ruby master Bug#19683] ruby-3.3.0-preview1 does not build with BSD make without --with-baseruby
by jeremyevans0 (Jeremy Evans) 19 Dec '23

19 Dec '23

Issue #19683 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #19683: ruby-3.3.0-preview1 does not build with BSD make without --with-baseruby https://bugs.ruby-lang.org/issues/19683 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0preview1 (2023-05-12 master a1b01e7701) [x86_64-openbsd7.3] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ruby-3.3.0-preview1 does not build with BSD make without `--with-baseruby`. However, it builds fine with GNU make and when using BSD make with `--with-baseruby`. Previous Ruby tarball releases have built fine with BSD make without `--with-baseruby`, so this issue has been introduced recently. When building with BSD make without `--with-baseruby`, building fails after generating RI format with: ``` /bin/sh: false: not found *** Error 127 in . (exts.mk:94 'ruby': @make UPDATE_LIBRARIES=no EXTENCS=dmyenc.o BASERUBY=echo\ executable\ host\ ruby\ is\ required.\ \ ...) *** Error 2 in /home/jeremy/local/ruby-3.3.0-preview1 (Makefile:948 'build-ext': @make -f exts.mk libdir="/usr/local/lib" LIBRUBY_EXTS=./...) ``` -- https://bugs.ruby-lang.org/

2 4

[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:112119] [Ruby master Bug#19392] Endless method vs and/or
by zverok (Victor Shepelev) 09 Dec '23

09 Dec '23

Issue #19392 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #19392: Endless method vs and/or https://bugs.ruby-lang.org/issues/19392 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Backport: 2.7: DONTNEED, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- [Discovered](https://twitter.com/lucianghinda/status/1617783952353406977) by Lucian Ghinda: ```ruby def test = puts("foo") and puts("bar") # prints "bar" immediately test # prints "foo" ``` It seems that it is a parser error, right?.. ```ruby RubyVM::AbstractSyntaxTree.parse('def test = puts("foo") and puts("bar")') # => # (SCOPE@1:0-1:38 # tbl: [] # args: nil # body: # (AND@1:0-1:38 # (DEFN@1:0-1:22 # mid: :test # body: # (SCOPE@1:0-1:22 # tbl: [] # args: # (ARGS@1:0-1:8 pre_num: 0 pre_init: nil opt: nil first_post: nil post_num: 0 post_init: nil rest: nil kw: nil kwrest: nil block: nil) # body: (FCALL@1:11-1:22 :puts (LIST@1:16-1:21 (STR@1:16-1:21 "foo") nil)))) # (FCALL@1:27-1:38 :puts (LIST@1:32-1:37 (STR@1:32-1:37 "bar") nil)))) ``` E.g. it is parsed as ```ruby (def test = puts("foo")) and (puts("bar")) ``` ...which is hardly intentional or have any practical use. The rightly parsed code in this case _can_ have practical use, like ```ruby def write(data) = File.write(@filename, data) == data.size or raise "Something went wrong" ``` -- https://bugs.ruby-lang.org/

12 19

[ruby-core:114722] [Ruby master Bug#19877] Non intuitive behavior of syntax only applied to literal value
by tompng (tomoya ishida) 07 Dec '23

07 Dec '23

Issue #19877 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19877: Non intuitive behavior of syntax only applied to literal value https://bugs.ruby-lang.org/issues/19877 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-09-08T23:08:32Z master b635a66e95) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Non intuitive behavior of syntax only applied to literal value Some ruby syntax is only applied to literal value. ~~~ruby def 1.foo; end # receiver is a literal, it is Syntax Error /(?<a>)/ =~ s # receiver is regexp literal, it will assign to local variable if cond1..cond2; end # range-like syntax appears in condition, it is flipflop ~~~ If it is wrapped with parenthesis, the behavior seems not intuitive for me, and YARP parses it differently. ~~~ruby def (1).foo; end # Syntax Error def ((1;1)).foo; end # Syntax Error def ((;1)).foo; end # Syntax OK def ((1+1;1)).foo; end # Syntax OK def ((%s();1)).foo; end # Syntax Error def ((%w();1)).foo; end # Syntax OK def ("#{42}").foo; end # Syntax Error def (:"#{42}").foo; end # Syntax OK (/(?<a>)/) =~ s # assigns to a (;/(?<a>)/) =~ s # does not assigns (%s();/(?<a>)/) =~ s # assigns to a (%w();/(?<a>)/) =~ s # does not assigns (1; (2; 3; (4; /(?<a>)/))) =~ s # assigns to a (1+1; /(?<a>)/) =~ s # does not assign if ((cond1..cond2)); end # flipflop if (; cond1..cond2); end # range if (1; cond1..cond2); end # flipflop if (%s(); cond1..cond2); end # flipflop if (%w(); cond1..cond2); end # range if (1; (2; (3; 4; cond1..cond2))); end # flipflop if (1+1; cond1..cond2); end # range ~~~ I expect YARP and parse.y parses same. I expect all parenthesis-wrapped result same. I think it is simple and intuitive if parenthesis-wrapped code always behaves different from non-wrapped code because there are more complex variation like this ~~~ruby def (class A; 1; end).foo; end (break; /?<a>/) =~ s class A; /?<a>/; end =~ s ~~~ -- https://bugs.ruby-lang.org/

4 5

[ruby-core:114251] [Ruby master Bug#19779] `eval "return"` at top level raises `LocalJumpError`
by andrykonchin (Andrew Konchin) 07 Dec '23

07 Dec '23

Issue #19779 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #19779: `eval "return"` at top level raises `LocalJumpError` https://bugs.ruby-lang.org/issues/19779 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Wondering whether it's intentional behaviour. It seems it's the only difference I've noticed between calling `return` with and without `eval`: ``` ruby -e 'return' ruby -e 'eval "return"' (eval):1:in `<main>': unexpected return (LocalJumpError) from -e:1:in `eval' from -e:1:in `<main>' ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:114785] [Ruby master Bug#19886] "default->bundled gem" warning is not shown under "bundle exec"
by mame (Yusuke Endoh) 06 Dec '23

06 Dec '23

Issue #19886 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #19886: "default->bundled gem" warning is not shown under "bundle exec" https://bugs.ruby-lang.org/issues/19886 * Author: mame (Yusuke Endoh) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` $ cat Gemfile source "https://rubygems.org" $ cat test.rb require "base64" $ bundle exec ruby test.rb $ ``` In this situation, `bundle exec ruby test.rb` should print a warning: base64 which will be not part of the default gems since Ruby 3.4.0. Note that `ruby test.rb` shows the warning, which is not needed (see #19885). ``` $ ruby test.rb test.rb:1: warning: base64 which will be not part of the default gems since Ruby 3.4.0 ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:113180] [Ruby master Feature#19588] Allow Comparable#clamp(min, max) to accept nil as a specification
by kyanagi (Kouhei Yanagita) 30 Nov '23

30 Nov '23

Issue #19588 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Feature #19588: Allow Comparable#clamp(min, max) to accept nil as a specification https://bugs.ruby-lang.org/issues/19588 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- `Comparable#clamp(min, max)` (with two arguments) accepts `nil`. This behaves the same as beginless/endless Range. ~~~ruby 5.clamp(nil, 0) # => 0 5.clamp(10, nil) # => 10 5.clamp(..0) # => 0 5.clamp(10..) # => 10 ~~~ This behavior is not documented. Presumably, this was not introduced intentionally. The old Rubies did not accept accept a `Range` argument. In Ruby 2.7, accepting `Range` as an argument was introduced. At that time, the approach of passing `nil` as a two-argument method was also discussed but not adopted, and using Range was chosen instead. https://bugs.ruby-lang.org/issues/14784 However, in Ruby 3.0, the behavior of `clamp` has changed to accept `nil`. This change is not documented in the NEWS or the documentation for `clamp`, and I believe that it was not an intentional change. ~~~ % docker run -it --rm rubylang/all-ruby env ALL_RUBY_SINCE=ruby-2.4.0 ./all-ruby -e "p 5.clamp(0, nil)" ruby-2.4.0 -e:1:in `clamp': comparison of Integer with nil failed (ArgumentError) from -e:1:in `<main>' exit 1 ... ruby-2.7.8 -e:1:in `clamp': comparison of Integer with nil failed (ArgumentError) from -e:1:in `<main>' exit 1 ruby-3.0.0-preview1 5 ... ruby-3.2.2 5 ~~~ It seems that https://github.com/ruby/ruby/commit/a93da4970be44a473b7b42e7516eb2663dece2c3 brought about this change. How about making the current behavior a specification? It has been three years since the behavior changed, and I don't see much point in prohibiting `nil` now. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:111074] [Ruby master Bug#19160] cmp_clamp arguments
by kaiquekandykoga 13 Nov '23

13 Nov '23

Issue #19160 has been reported by kaiquekandykoga (Kaíque Koga). ---------------------------------------- Bug #19160: cmp_clamp arguments https://bugs.ruby-lang.org/issues/19160 * Author: kaiquekandykoga (Kaíque Koga) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-freebsd13.1] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- If clamp receives min higher than max, it will raise an exception. The message says *min argument must be smaller than max argument* , but min can actually be equal to max too. Patch https://github.com/ruby/ruby/pull/6802. -- https://bugs.ruby-lang.org/

2 1