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

[ruby-core:111434] [Ruby master Feature#19261] `Data#members` is not important
by ko1 (Koichi Sasada) 04 Dec '24

04 Dec '24

Issue #19261 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #19261: `Data#members` is not important https://bugs.ruby-lang.org/issues/19261 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal ---------------------------------------- `Data#members` is defined but it is calculated by `self.class.members` (in other words, `#members` is a shorthand for `self.class.members`). So it is better to remove this method. ```ruby P = Data.define(:x, :y) p P.new(1, 2).members #=> [:x, :y] Group = Data.define(:name, :members) gs = Group.new('SasadaFamily', %w(ko1 yuki)) p gs.members #=> ["ko1", "yuki"] ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:118003] [Ruby master Bug#20506] Failure compiling Ruby 3.4.0-preview1 on aarch64 on a mac and linux (Ubuntu 24.04)
by schneems (Richard Schneeman) 29 Nov '24

29 Nov '24

Issue #20506 has been reported by schneems (Richard Schneeman). ---------------------------------------- Bug #20506: Failure compiling Ruby 3.4.0-preview1 on aarch64 on a mac and linux (Ubuntu 24.04) https://bugs.ruby-lang.org/issues/20506 * Author: schneems (Richard Schneeman) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I was unable to compile Ruby 3.4.0-preview1 on Ubuntu 24.04 via Github Actions. As the logs are not retained indefinitely here's a link to the compilation failure: https://gist.github.com/schneems/bc6bdd6fba08ff6bfdd1bce8d76c457d The relevant errors seem to be in linking yjit: ``` touch yjit/target/release/libyjit.a partial linking yjit/target/release/libyjit.a into yjit/target/release/libyjit.o linking miniruby /usr/bin/ld: yjit/target/release/libyjit.o: in function `__multc3': /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:33:(.text.__multc3+0x30c): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:34:(.text.__multc3+0x394): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:42:(.text.__multc3+0x7f4): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:43:(.text.__multc3+0x864): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:47:(.text.__multc3+0x8c4): undefined reference to `__builtin_copysignq' /usr/bin/ld: yjit/target/release/libyjit.o:/cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:38: more undefined references to `__builtin_copysignq' follow collect2: error: ld returned 1 exit status make: *** [Makefile:298: miniruby] Error 1 /tmp/lib/build_script.rb:118:in `pipe': Command failed debugflags="-g" ./configure --disable-install-doc --prefix /tmp/d20240524-1-bdq0bj/prefix --enable-load-relative --enable-shared --enable-yjit && make -j16 && make install (RuntimeError) from /tmp/lib/build_script.rb:158:in `block in build' from /tmp/lib/build_script.rb:152:in `chdir' from /tmp/lib/build_script.rb:152:in `build' from /tmp/lib/build_script.rb:65:in `block in run_build_script' from /usr/lib/ruby/3.2.0/tmpdir.rb:94:in `mktmpdir' from /tmp/lib/build_script.rb:61:in `run_build_script' from /tmp/build.rb:8:in `<main>' ``` Here's the GHA link: https://github.com/heroku/docker-heroku-ruby-builder/actions/runs/922553814…. This is the Dockerfile for Ubuntu 24.04 https://github.com/heroku/docker-heroku-ruby-builder/blob/73bdda974811717ba…. I'm able to reproduce the failure locally: ``` $ git clone https://github.com/heroku/docker-heroku-ruby-builder $ cd docker-heroku-ruby-builder $ export DOCKER_DEFAULT_PLATFORM=linux/arm64 $ bin/activate_docker heroku-24 $ bin/build_ruby heroku-24 3.4.0-preview1 # Fails ``` Full output https://gist.github.com/schneems/cfa21847228d48e6bbe27463deae6745. I'm also seeing failures when using `ruby-install` on my mac (ARM), the error message is different so I'm not sure if it's the same problem or unrelated: https://gist.github.com/schneems/12af87e967126c7bfa319645b00015b3 -- https://bugs.ruby-lang.org/

6 11

[ruby-core:116760] [Ruby master Feature#20265] Deprecate and remove rb_newobj and rb_newobj_of
by peterzhu2118 (Peter Zhu) 28 Nov '24

28 Nov '24

Issue #20265 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #20265: Deprecate and remove rb_newobj and rb_newobj_of https://bugs.ruby-lang.org/issues/20265 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/9964 I’m proposing deprecating and removing the rb_newobj and rb_newobj_of APIs because they are difficult to use, fragile to use, and requires knowledge of the internal implementation of data types in Ruby. The rb_newobj function creates a T_NONE object. T_NONE objects are tricky to deal with since T_NONE objects cannot be marked, T_NONE objects are not reclaimed by the GC, and changing the object to other types require internal knowledge about the data type. T_NONE objects are not allowed to be marked, so it cannot be GC managed. Since T_NONE objects are skipped during sweeping, it will leak Ruby heap memory if the developer never changes the object to another type. Changing a T_NONE object to another type is tricky. For example, T_STRING objects have many flags for embedded, shared, shared root, encoding, coderange, etc. Many of these flags are not public, preventing direct use by developers. Developers must understand these flags to convert a T_NONE object into a T_STRING object. While the rb_newobj_of function is easier to use than the rb_newobj function, it still requires developers to understand flags, meaning some issues of rb_newobj also apply to rb_newobj_of. Below is the usage of RB_NEWOBJ, rb_newobj, rb_newobj_of, RB_NEWOBJ_OF with vendored Ruby and comments removed. You can see that there are very few gems using these APIs and all are from over a decade ago (the most recent one is from 2011). ``` 2009-11-18 /srv/gems/bleak_house-7.2/ruby/ruby-1.8.7.patch:@@ -438,10 +438,8 @@ rb_newobj() 2023-07-01 /srv/gems/daqing_rucaptcha-3.2.2/ext/rucaptcha/target/release/build/rb-sys-6bdd5b2895b9570a/out/bindings-0.9.78-arm64-darwin22-3.2.2.rs: pub fn rb_newobj() -> VALUE; 2023-07-01 /srv/gems/daqing_rucaptcha-3.2.2/ext/rucaptcha/target/release/build/rb-sys-6bdd5b2895b9570a/out/bindings-0.9.78-arm64-darwin22-3.2.2.rs: pub fn rb_newobj_of(klass: VALUE, flags: VALUE) -> VALUE; 2010-08-06 /srv/gems/langscan-1.2/ext/langscan/ruby/compat/ripper/ripper.c: NODE *n = (NODE*)rb_newobj(); 2011-02-03 /srv/gems/memprof-0.3.10/ext/memprof.c: VALUE ret = rb_newobj(); 2011-02-03 /srv/gems/memprof-0.3.10/ext/tracers/objects.c: last_obj = orig_rb_newobj(); 2006-02-28 /srv/gems/refe-0.8.0.3/data/refe/function_source/rb/newobj:rb_newobj() 2006-02-28 /srv/gems/refe-0.8.0.3/data/refe/function_source/rb/node/newnode: NODE *n = (NODE*)rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: prov = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: req = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: conf = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: obso = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/file.c: file = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/source.c: src = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/source.c: src = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/source.c: src = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/version.c: ver = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/version.c: ver = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/version.c: ver = rb_newobj(); 2006-11-30 /srv/gems/sydparse-1.2.0/sydparse.c: syd_scope = (struct SCOPE*)rb_newobj(); 2006-11-30 /srv/gems/sydparse-1.2.0/sydparse.y: syd_scope = (struct SCOPE*)rb_newobj(); ``` -- https://bugs.ruby-lang.org/

5 7

[ruby-core:111247] [Ruby master Feature#19191] Implicit console input transcoding is more desirable
by YO4 (Yoshinao Muramatsu) 22 Nov '24

22 Nov '24

Issue #19191 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Feature #19191: Implicit console input transcoding is more desirable https://bugs.ruby-lang.org/issues/19191 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Priority: Normal ---------------------------------------- In response to Bug #18353, STDIN.internal_encoding are set and encoding is converted explcitly on Windows platform. For example, ```[STDIN.external_encoding, STDIN.internal_encoding] # => [Encoding::Windows-31J, Encoding::UTF-8]``` if STDIN is console. I feel that internal_encoding should be reserved for specific applications. And I think setting internal_encoding to STDIN is not foreseened. Today I found irb breaks STDIN encoding, like ``` >ruby -rirb -e "p [$stdin.external_encoding, $stdin.internal_encoding]; IRB.setup(''); IRB::Irb.new(); p [$stdin.external_encoding, $stdin.internal_encoding]" [#<Encoding:Windows-31J>, #<Encoding:UTF-8>] [#<Encoding:UTF-8>, nil] ``` We know input has console code page encoding. So we always can convert encoding from console code page to io_input_encoding(). ### proposal when reading from console on Windows, input encoding is enfoced to console code page and encoding conversion is implicitly applied. when ```set_encoding("UTF-8")``` implicitly converts console code page to UTF-8. when ```set_encoding("CP437", "UTF-8")``` implicitly converts console code page to UTF-8. external_encoding is ignored. binmode or binary input method is not affected by these specifications. set_encoding, etc. will continue to work as before, and this specification will affect only when encoding conversion on read (NEED_READCONV() and make_readconv()). -- https://bugs.ruby-lang.org/

2 5

[ruby-core:113489] [Ruby master Bug#19642] Remove vectored read/write from `io.c`.
by ioquatix (Samuel Williams) 20 Nov '24

20 Nov '24

Issue #19642 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19642: Remove vectored read/write from `io.c`. https://bugs.ruby-lang.org/issues/19642 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- https://github.com/socketry/async/issues/228#issuecomment-1546789910 is a comment from the kernel developer who tells us that `writev` is always worse than `write` system call. A large amount of complexity in `io.c` comes from optional support from `writev`. So, I'd like to remove support for `writev`. I may try to measure the performance before/after. However it may not show much difference, except that the implementation in `io.c` can be much simpler. -- https://bugs.ruby-lang.org/

5 9

[ruby-core:111966] [Ruby master Feature#19366] Rename/alias Refinedment#refined_class => #refined_module
by zverok (Victor Shepelev) 19 Nov '24

19 Nov '24

Issue #19366 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19366: Rename/alias Refinedment#refined_class => #refined_module https://bugs.ruby-lang.org/issues/19366 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- In #12737, `Refinement#refined_class` is introduced. As "module" is more generic concept than "class", the name misleadingly implies that either this method doesn't returns refined _modules_, or modules can't be refined. This is obviously not true and trivially disproved: ```ruby module Refs refine Enumerable do def foo = puts 'foo' end end Refs.refinements[0].refined_class #=> Enumerable. Which is, well, not a class. # The refinement is usable, so it is not a mute concept: using Refs [1, 2, 3].foo # prints "foo" successfully ``` I believe we refer to "modules" when some feature applies to modules and classes. Unless there is some deeper consideration for the current naming (I don't see justification in #12737, but I might miss something), the method should be renamed or aliased. PS: Sorry for a huge amount of "nitpicky" issues after the version release. Typically, those concerns emerge while I am working on the [changelog](https://rubyreferences.github.io/rubychanges/), and I am usually trying to start the work at least a month before the release. Unfortunately, due to you-know-what, I was unable to do it in time this year. After the 3.2 changelog, I plan to switch to the "master changelog" approach (following the development with the "current unreleased changes" document) this year. Unless I'll be unable to due to reasons not in my control. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:117240] [Ruby master Feature#20350] Return chilled string from Symbol#to_s
by Dan0042 (Daniel DeLorme) 12 Nov '24

12 Nov '24

Issue #20350 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20350: Return chilled string from Symbol#to_s https://bugs.ruby-lang.org/issues/20350 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- During Ruby 2.7 development there was an attempt to return a frozen string from Symbol#to_s (#16150#note-22) This had to be rolled back due to incompatibility, but now we have chilled strings (#20205) Symbol#to_s can safely return a chilled string, giving developers time to fix warnings before switching to a frozen string. -- https://bugs.ruby-lang.org/

6 9

[ruby-core:118976] [Ruby master Bug#20704] Windows: `-C` option does not work for multibyte path name
by nobu (Nobuyoshi Nakada) 08 Nov '24

08 Nov '24

Issue #20704 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20704: Windows: `-C` option does not work for multibyte path name https://bugs.ruby-lang.org/issues/20704 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Related to [Bug #20699]. ``` C:> \Ruby33-x64\bin\ruby.exe -C xテスト_test -ep \Ruby33-x64\bin\ruby.exe: Can't chdir to xテスト_test (fatal) ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:117968] [Ruby master Bug#20501] ruby SEGV
by akr (Akira Tanaka) 04 Nov '24

04 Nov '24

Issue #20501 has been reported by akr (Akira Tanaka). ---------------------------------------- Bug #20501: ruby SEGV https://bugs.ruby-lang.org/issues/20501 * Author: akr (Akira Tanaka) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I encountered SEGV of ruby. ``` % ./ruby -v ruby 3.4.0dev (2024-05-22T06:59:19Z master 5613d6e95b) [x86_64-linux] % ./ruby t.rb t.rb:33: [BUG] Segmentation fault at 0x00007fc243696098 ruby 3.4.0dev (2024-05-22T06:59:19Z master 5613d6e95b) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:0000 s:4294967313 e:000018 METHOD t.rb:33 c:0002 p:0022 s:0006 e:000005 EVAL t.rb:52 [FINISH] c:0001 p:0000 s:0003 E:000350 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- t.rb:52:in '<main>' t.rb:33:in 'create_no_file' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000055a1cdc8bb9c RBP: 0x000055a1cee844b0 RSP: 0x00007ffcde5cdae0 RAX: 0x00007fc2436960a0 RBX: 0x00007fba43795f68 RCX: 0x0000000000000000 RDX: 0x000055a1cf115cf0 RDI: 0x0000000000000009 RSI: 0x00007fba28526860 R8: 0x00007fba436960a1 R9: 0x0000000000000000 R10: 0x00007fba28526860 R11: 0x0000000000000003 R12: 0x0000000000000006 R13: 0x00007fba2853b698 R14: 0x0000000d00000009 R15: 0x0000000000000b21 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- /home/ruby/t2/ruby/ruby(rb_print_backtrace+0x14) [0x55a1cdcae243] /home/ruby/t2/ruby/vm_dump.c:820 /home/ruby/t2/ruby/ruby(rb_vm_bugreport) /home/ruby/t2/ruby/vm_dump.c:1151 /home/ruby/t2/ruby/ruby(rb_bug_for_fatal_signal+0xf8) [0x55a1cde5abe8] /home/ruby/t2/ruby/error.c:1108 /home/ruby/t2/ruby/ruby(sigsegv+0x44) [0x55a1cdbf7864] /home/ruby/t2/ruby/signal.c:929 /lib/x86_64-linux-gnu/libc.so.6(0x7fba438f8050) [0x7fba438f8050] /home/ruby/t2/ruby/ruby(vm_exec_handle_exception+0x2ac) [0x55a1cdc8bb9c] /home/ruby/t2/ruby/vm.c:2782 ... ``` `t.rb` and the full crash report are attached. ---Files-------------------------------- t.rb (1.27 KB) crash.txt (15.8 KB) -- https://bugs.ruby-lang.org/

7 14

[ruby-core:118932] [Ruby master Bug#20693] Dir.tmpdir should perform a real access check before warning about writability
by kjtsanaktsidis (KJ Tsanaktsidis) 22 Oct '24

22 Oct '24

Issue #20693 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20693: Dir.tmpdir should perform a real access check before warning about writability https://bugs.ruby-lang.org/issues/20693 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The code in `Dir.tmpdir` attempts to warn the user if their temp directory is deficient for some reason: ```ruby case when !stat.directory? warn "#{name} is not a directory: #{dir}" when !stat.writable? warn "#{name} is not writable: #{dir}" when stat.world_writable? && !stat.sticky? warn "#{name} is world-writable: #{dir}" else break dir end ``` This check for writability is looking at the user/group/world access bits on the stat output, and determining if the user running Ruby is allowed to write to the temp directory based on that. However, modern operating systems contain other mechanisms apart from the user/group/world bits which can grant access to a directory that would otherwise be denied, or vice versa. Things like: * Posix ACL's * Linux's capabilities like CAP_DAC_OVERRIDE * Linux Security Modules like SELinux or AppArmor * Syscall filters like Linux's seccomp * Granular capability systems like FreeBSD's Capsicum * OpenBSD's pledge and unveil * Windows too has a rich ACL system for controlling filesystem access To address this, we should call `File.writable?` instead of `stat.writable?`, which asks the system whether the file is writable using the `euidaccess()` function if available. On Linux/glibc, at least, this will issue an `access(2)` syscall, and the Kernel can take all of the above into account. n.b. if Ruby is running as suid, then glibc currently will NOT ask the kernel to perform the access check in `euidaccess()`, and instead does a similar thing to what `Stat#writable?` does (https://github.com/bminor/glibc/blob/7f04bb4e49413bd57ac3215f3480b09ae71319…) This is because of the relatively new `faccessat2(2)` syscall is required to do this properly, and there is some ecosystem issues with leveraging this by default (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1900021) Since running Ruby as suid is probably a very bad idea anyway, and the glibc implementation isn't any worse than the `Stat#writable?` one, this seems OK though. -- https://bugs.ruby-lang.org/

4 8