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

[ruby-core:112446] [Ruby master Bug#19442] Remove USE_RINCGC flag
by eightbitraptor (Matthew Valentine-House) 28 Dec '23

28 Dec '23

Issue #19442 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Bug #19442: Remove USE_RINCGC flag https://bugs.ruby-lang.org/issues/19442 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- [GitHub PR #7317](https://github.com/ruby/ruby/pull/7313) Ruby doesn't compile when USE_RINCGC is disabled. It's also not being tested in CI. As @nobu has pointed out in comments on the PR, fixing it is simple. I think there are 2 approaches we could take: 1. Remove `USE_RINCGC` entirely and always run with incremental GC enabled. We have a precedent for this: `USE_RGENGC=0` was removed [in this commit](https://github.com/ruby/ruby/commit/62c2b8c74e47652fc5bbaf6150f4acd… almost 3 years ago. `USE_RINCGC=0` is in a similar state. It has been broken for almost a year (since [this commit](https://github.com/ruby/ruby/commit/dde164e968e382d50b07ad455946888…) and [disabled in CI for more than 2 years](https://github.com/ruby/ruby/commit/46d3ea2c2569e2e5a9ee3e7e206f07f0…. 2. We could fix `USE_RINCGC`. If we do this we should re-enable the CI task so that we continue to keep it working in the future. I am very much in favour of option 1, because I don't think this flag is being actively used, and removing it will simplify the code and reduce the cognitive overhead of working with the GC. However I am happy to defer to the team here. -- https://bugs.ruby-lang.org/

6 9

[ruby-core:115208] [Ruby master Feature#19982] Bump required Visual Studio version to 2015 after 3.3
by kddnewton (Kevin Newton) 27 Dec '23

27 Dec '23

Issue #19982 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #19982: Bump required Visual Studio version to 2015 after 3.3 https://bugs.ruby-lang.org/issues/19982 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- Visual Studio 2013 is finally being EOL'd next April. (https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-servicing#old…) Let's drop support for it after Ruby 3.3 is released. If we bump the required version to Visual Studio 2015, we'll get better C99 support and be able to rely on some more standards. Personally I'm excited about `snprintf` being actually implemented. (https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-language-conforma…) As support for the argument, CPython requires VS2017 (https://github.com/python/cpython/blob/main/PCbuild/readme.txt) and gnulib requires VS2015(https://www.gnu.org/software/gnulib/manual/html_node/Supported-Platf…. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:113951] [Ruby master Bug#19738] `ObjectSpace.each_object.to_a` crashes in `make runirb`.
by ioquatix (Samuel Williams) 26 Dec '23

26 Dec '23

Issue #19738 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19738: `ObjectSpace.each_object.to_a` crashes in `make runirb`. https://bugs.ruby-lang.org/issues/19738 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` > make runirb RUBY_ON_BUG='gdb -x ./.gdbinit -p' ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems -r irb -e 'IRB.start("make runirb")' irb(main):001:0> ObjectSpace.each_object.to_a Assertion Failed: ./vm_method.c:1366:callable_method_entry_or_negative:RB_TYPE_P(klass, T_CLASS) || RB_TYPE_P(klass, T_ICLASS) ruby 3.3.0dev (2023-06-19T19:19:45Z master 9ff4399dec) [arm64-darwin22] ``` I have no idea why. ---Files-------------------------------- error.txt (12.9 KB) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:114345] [Ruby master Bug#19831] warning message of linker with macOS Sonoma beta
by hsbt (Hiroshi SHIBATA) 26 Dec '23

26 Dec '23

Issue #19831 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19831: warning message of linker with macOS Sonoma beta https://bugs.ruby-lang.org/issues/19831 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Xcode 15 beta and macOS Sonoma beta show the following warnings with `make` ``` (snip) linking miniruby ld: warning: ignoring duplicate library '-lpthread' miniruby: replacing existing signature exe/ruby: replacing existing signature builtin_binary.inc updated compiling builtin.c linking static-library libruby.3.3-static.a linking ruby ld: warning: ignoring duplicate library '-lgmp' ld: warning: ignoring duplicate library '-ldl' ld: warning: ignoring duplicate library '-lobjc' ld: warning: ignoring duplicate library '-lpthread' ld: warning: ignoring duplicate library '-lpthread' (snip) ``` I'm not investigate that yet. It may be caused by `ld-prime` that is new linker of macOS platform. ``` $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables package-id: com.apple.pkg.CLTools_Executables version: 15.0.0.0.1.1690355577 volume: / location: / install-time: 1690967267 ``` -- https://bugs.ruby-lang.org/

1 3

[ruby-core:111739] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
by zverok (Victor Shepelev) 23 Dec '23

23 Dec '23

Issue #19324 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19324: Enumerator.product => Enumerable#product https://bugs.ruby-lang.org/issues/19324 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- I know it might be too late after introducing a feature and releasing a version, but I find `Enumerator.product` quite confusing, and can't find any justification in #18685. **Problem 1: It is `Array#product` but `Enumerator.product`** ```ruby [1, 2].product([4, 5]) # => [[1, 4], [1, 5], [2, 4], [2, 5]] # Usually, when we add methods to Enumerable/Enumerator which # already array had before, it is symmetric, say... [1, nil, 2, 3].compact #=> [1, 2, 3] [1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2] # But not in this case: [1, 2].lazy.product([4, 5]).first(2) # undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError) # Because you "just" need to change it to: Enumerator.product([1, 2].lazy, [4, 5]).first(2) # => [[1, 4], [1, 5]] ``` No other method was "promoted" from Array this way And in general, I believe core methods tend to belong to the first object in the expression and not be free module methods, Elixir style. **Problem 2: It is one letter different from `Enumerator.produce`** I understand I might be biased here (as a person who proposed `produce`), and that method is not as popular (yet?) as I hoped, but still, two methods that do completely different things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse them unless you did a lot of math and "product" is firmly set for set product in your head). I believe that EITHER of two problems would be concerning enough, but the combination of them seems to be a strong enough argument to make the change?.. (Maybe with graceful deprecation of module method in one next version, but, considering the Ruby 3.2 is just released, maybe vice versa, fix the problem in the next minor release?..) -- https://bugs.ruby-lang.org/

6 17

[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:115188] [Ruby master Bug#19977] (nil..nil) === x can raise an exception, differing from Range#cover?
by kyanagi (Kouhei Yanagita) 22 Dec '23

22 Dec '23

Issue #19977 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #19977: (nil..nil) === x can raise an exception, differing from Range#cover? https://bugs.ruby-lang.org/issues/19977 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-27T03:13:17Z master f9f0cfe785) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I investigated Range#=== and Range#cover?, and found that the only difference in behavior between them would be that `(nil..nil) === x` could throw an exception. ``` % ~/tmp/ruby-master/bin/ruby -v ruby 3.3.0dev (2023-10-27T03:13:17Z master f9f0cfe785) [arm64-darwin22] ``` ``` % ~/tmp/ruby-master/bin/ruby -e 'p (nil..nil) === "a"' -e:1:in `===': cannot determine inclusion in beginless/endless ranges (TypeError) p (nil..nil) === "a" ^^^ from -e:1:in `<main>' ``` ``` % ~/tmp/ruby-master/bin/ruby -e 'p (nil..nil).cover?("a")' true ``` Is this difference intended? According to NEWS, `Range#===` uses `cover?` since Ruby 2.6 (For `String`, since Ruby 2.7). Following this, `(nil..nil) === x` should not throw an exception in the same way as `(nil..nil).cover?(x)`. history: `(nil..nil) === "a"` throws an exception since https://github.com/ruby/ruby/commit/04a92a6. For "linear objects" (`Integer`, `Float`, `Numeric`, `Time`), it has beed fixed not to throw an exception on https://github.com/ruby/ruby/commit/fb17c83. related issues: * [Bug #15449] Range#=== is not using cover in Ruby 2.6 * [Bug #18580] Range#include? inconsistency for beginless String ranges * [Bug #19533] Behavior of ===/include? on a beginless/endless range (nil..nil) changed in ruby 3.2 -- https://bugs.ruby-lang.org/

2 5

[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:115197] [Ruby master Misc#19980] Is the Ruby 3.3 ABI frozen?
by mdalessio (Mike Dalessio) 13 Dec '23

13 Dec '23

Issue #19980 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Misc #19980: Is the Ruby 3.3 ABI frozen? https://bugs.ruby-lang.org/issues/19980 * Author: mdalessio (Mike Dalessio) * Status: Open * Priority: Normal ---------------------------------------- I'm a co-maintainer of [rake-compiler-dock](https://github.com/rake-compiler/rake-compiler-dock) which is used to build precompiled native packages for some gems, including nokogiri, sqlite3, grpc, re2, and ruby-magic. In the past, precompiled native gems generally released support for a new version of Ruby days or weeks after Ruby's release (for example, [Nokogiri v1.14.0 released on 2023-01-12](https://nokogiri.org/CHANGELOG.html)) In some cases, the lack of native gem support has slowed user adoption of the new version of Ruby. This year, I'd like to see native gems release Ruby 3.3 support before the final version is released. This will encourage testing of Ruby 3.3 previews and allow users to immediately upgrade to Ruby 3.3 final when it is released. To do that, I would like to cut a release of the rake-compiler-dock gem (and its [build containers](https://github.com/rake-compiler/rake-compiler-dock/pkgs/contai…) that supports Ruby 3.3 as soon as possible (I already have a feature branch mostly working based on 3.3.0_preview1 at https://github.com/rake-compiler/rake-compiler-dock/pull/105) Is the Ruby 3.3 ABI frozen now? If I build a native gem against Ruby 3.3.0_preview2, is there any reason to believe that it wouldn't work with Ruby 3.3 final when it is released? Thank you for any guidance you can provide. -- https://bugs.ruby-lang.org/

3 6