March 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:120819] [Ruby master Bug#21097] `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism
by tompng (tomoya ishida) 11 Mar '25

11 Mar '25

Issue #21097 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21097: `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism https://bugs.ruby-lang.org/issues/21097 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-27T08:19:32Z master c3c7300b89) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby x = a rescue b in c (x = (a rescue b)) in c # parse.y, prism(ruby 3.4) x = (a rescue (b in c)) # prism(ruby 3.5) ~~~ ~~~ruby def f = a rescue b in c #=> true(parse.y), :f(prism) (def f = (a rescue b)) in c # parse.y def f = (a rescue (b in c)) # prism ~~~ There is no difference between prism and parse.y parsing these codes ~~~ruby a rescue b in c # a rescue (b in c) x = a rescue b # x = (a rescue b) x = b in c # (x = b) in c def f = a rescue b # def f = (a rescue b) def f = b in c # (def f = a) in b ~~~ -- https://bugs.ruby-lang.org/

5 6

[ruby-core:120817] [Ruby master Bug#21096] Ruby hangs up when compiling for bytecode on AArch64 emulated by QEMU
by midnight (Sarun R) 11 Mar '25

11 Mar '25

Issue #21096 has been reported by midnight (Sarun R). ---------------------------------------- Bug #21096: Ruby hangs up when compiling for bytecode on AArch64 emulated by QEMU https://bugs.ruby-lang.org/issues/21096 * Author: midnight (Sarun R) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hello, We are experiencing issues when using [Bootsnap](https://github.com/Shopify/bootsnap) for production container image building, specifically when running `bundle exec bootsnap precompile --gemfile` on an emulated ARM64 environment on AMD64 hosts. Here are more details: * Bootsnap is a Ruby gem for bytecode caching, which speeds up loading times. It achieves this by calling `RubyVM::InstructionSequence.compile_file` and `RubyVM::InstructionSequence.load_from_binary`. * When running `bundle exec bootsnap precompile --gemfile` in the environment described (using QEMU to emulate the AArch64 instruction set), the process can compile and generate some bytecode but eventually hangs. * The hang seems random, occurring at different points during the process. * According to [a Rails GitHub issue](https://github.com/rails/rails/issues/54039), the issue affects both `Docker` and `containerd`, as well as native Linux and macOS environments. * From [a Bootsnap GitHub issue](https://github.com/Shopify/bootsnap/issues/495), the problem likely doesn't occur in Ruby `3.2.6` but appears in later versions. * So far, the common factors observed are: * Emulated ARM64 on AMD64 CPUs (likely using QEMU) * Newer Ruby versions (e.g., 3.3 and 3.4) As a user, I don't have the expertise to debug the issue but am willing to gather more information if provided with sufficient instructions. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:121277] [Ruby master Bug#21178] Socket fails in Ractor
by getajobmike (Mike Perham) 10 Mar '25

10 Mar '25

Issue #21178 has been reported by getajobmike (Mike Perham). ---------------------------------------- Bug #21178: Socket fails in Ractor https://bugs.ruby-lang.org/issues/21178 * Author: getajobmike (Mike Perham) * Status: Open * ruby -v: 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I think these structures need to be frozen. ``` /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/socket.rb:1043:in 'Socket::HostnameResolutionStore#get_addrinfo': can not access non-shareable objects in constant Socket::HostnameResolutionStore::PRIORITY_ON_V6 by non-main ractor. (Ractor::IsolationError) from /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/socket.rb:724:in 'block in Socket.tcp_with_fast_fallback' from <internal:kernel>:168:in 'Kernel#loop' from /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/socket.rb:720:in 'Socket.tcp_with_fast_fallback' from /Users/mperham/.rubies/ruby-3.4.1/lib/ruby/3.4.0/socket.rb:661:in 'Socket.tcp' ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120878] [Ruby master Bug#21112] Type in error message when an incorrect key is used with WeakKeyMap
by andrykonchin (Andrew Konchin) 08 Mar '25

08 Mar '25

Issue #21112 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21112: Type in error message when an incorrect key is used with WeakKeyMap https://bugs.ruby-lang.org/issues/21112 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The `ObjectSpace::WeakKeyMap#[]=` method raises exception when key is either Symbol, Numeric or true/false/nil but error message looks like a bit incorrect: ```ruby m = ObjectSpace::WeakKeyMap.new m[:a] = 1 # 'ObjectSpace::WeakKeyMap#[]=': WeakKeyMap must be garbage collectable (ArgumentError) ``` The error message `WeakKeyMap must be garbage collectable` looks like should be `WeakKeyMap key must be garbage collectable`. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120811] [Ruby master Bug#21095] Prefer `uname -n` over `hostname` in tests.
by ioquatix (Samuel Williams) 08 Mar '25

08 Mar '25

Issue #21095 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21095: Prefer `uname -n` over `hostname` in tests. https://bugs.ruby-lang.org/issues/21095 * Author: ioquatix (Samuel Williams) * Status: Closed * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- It turns out that `hostname`, while a defacto standard, is not actually a standard in any official sense. On Linux, it's distributed as part of the `inettools` package, and while generally available on other platforms (BSD, Windows, MacOS), it isn't actually part of any standard. The `name(1)` system call and `uname(2)` command ARE standardised by POSIX and the Open Group, and are included in most base systems without the need to install extra packages (e.g. `inettools` on Linux). As such, I was requested by the Arch Linux Ruby maintainer, to prefer using `uname -n` as they would like to drop the dependency on `inettools`. See <https://gitlab.archlinux.org/archlinux/packaging/packages/inetutils/-/issue…> for more context. I've been asked if this can be back ported to 3.3 and 3.4 and while it's not strictly a bug, it will reduce friction in the distribution channels, so I'd like to propose that we backport to 3.4 and if possible 3.3 too. -- https://bugs.ruby-lang.org/

4 9

[ruby-core:120733] [Ruby master Bug#21046] Backport: TLS fix for ARM64
by nobu (Nobuyoshi Nakada) 08 Mar '25

08 Mar '25

Issue #21046 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21046: Backport: TLS fix for ARM64 https://bugs.ruby-lang.org/issues/21046 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- commit:f7059af50a31a4d27a04ace0beadb60616f3f971 Use no-inline version `rb_current_ec` on Arm64 The TLS across .so issue seems related to Arm64, but not Darwin. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:121262] [Ruby master Feature#18784] `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exceptions
by deivid 07 Mar '25

07 Mar '25

Issue #18784 has been updated by deivid (David Rodríguez). A keyword argument, then. Maybe `exception: true` ala `Kernel#system`? ---------------------------------------- Feature #18784: `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exceptions https://bugs.ruby-lang.org/issues/18784#change-112217 * Author: deivid (David Rodríguez) * Status: Open ---------------------------------------- In recent times, I've been having issues with these methods because they don't let you know when some issue happened while trying to remove the given folders/files. IMO most users expect all pre-existing folders/files that are passed to these methods to be actually removed by the methods. Instead, when this happens, errors are silently swallowed and normally the result is that you will get some other issue further down the road, making the problem hard to debug. The current workaround I'm using is to double check whether the files still exist after the method, and raise a custom error if they do, but I still can't see the original problem, so issues are similarly hard to debug. This is also a deviation from how `rm -rf` and `rm -f` work, since these tools finish with a failure exit code when they fail to remove the given files. Given that `fileutils` is intended to mimic shell functionality, I think this is just a bug. I think the intention of the `force` flag here is to: * Don't prompt for confirmation. * Ignore given arguments that are not files that already exist. But any issue other than that should not be swallowed, and in general I think the method should succeed if and only if the given list of file names does not exist after the methods are done. I think this is in line with the following note I get when I run `man rm`, but also suggests that this is not the standard behavior of "historical implementations" > COMPATIBILITY > > The rm utility differs from historical implementations in that the -f option only masks attempts to remove non-existent files instead of masking a large variety of errors. I implemented this at https://github.com/ruby/fileutils/pull/58, but treating this as a bug. I can also implement a more conservative for approach for users that might be using `FileUtils.rm_rf` or `FileUtils.rm_f` but don't really care if the files are removed or not. Alternative proposals would be `FileUtils.rm_rf(force: strict)`, or `FileUtils.strict_rm_rf`, but to be honest, if this is considered a breaking change, I would ship it as a new major version, and let users update their code to swallow errors themselves if they need to. Happy to hear any feedback! -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121261] [Ruby master Feature#18784] `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exceptions
by byroot (Jean Boussier) 07 Mar '25

07 Mar '25

Issue #18784 has been updated by byroot (Jean Boussier). The `!` for a version that raises is a Rails convention, and AFAIK always rejected for Ruby itself. So a keyword argument is more likely to be accepted. ---------------------------------------- Feature #18784: `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exceptions https://bugs.ruby-lang.org/issues/18784#change-112216 * Author: deivid (David Rodríguez) * Status: Open ---------------------------------------- In recent times, I've been having issues with these methods because they don't let you know when some issue happened while trying to remove the given folders/files. IMO most users expect all pre-existing folders/files that are passed to these methods to be actually removed by the methods. Instead, when this happens, errors are silently swallowed and normally the result is that you will get some other issue further down the road, making the problem hard to debug. The current workaround I'm using is to double check whether the files still exist after the method, and raise a custom error if they do, but I still can't see the original problem, so issues are similarly hard to debug. This is also a deviation from how `rm -rf` and `rm -f` work, since these tools finish with a failure exit code when they fail to remove the given files. Given that `fileutils` is intended to mimic shell functionality, I think this is just a bug. I think the intention of the `force` flag here is to: * Don't prompt for confirmation. * Ignore given arguments that are not files that already exist. But any issue other than that should not be swallowed, and in general I think the method should succeed if and only if the given list of file names does not exist after the methods are done. I think this is in line with the following note I get when I run `man rm`, but also suggests that this is not the standard behavior of "historical implementations" > COMPATIBILITY > > The rm utility differs from historical implementations in that the -f option only masks attempts to remove non-existent files instead of masking a large variety of errors. I implemented this at https://github.com/ruby/fileutils/pull/58, but treating this as a bug. I can also implement a more conservative for approach for users that might be using `FileUtils.rm_rf` or `FileUtils.rm_f` but don't really care if the files are removed or not. Alternative proposals would be `FileUtils.rm_rf(force: strict)`, or `FileUtils.strict_rm_rf`, but to be honest, if this is considered a breaking change, I would ship it as a new major version, and let users update their code to swallow errors themselves if they need to. Happy to hear any feedback! -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121260] [Ruby master Feature#18784] `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exceptions
by Dan0042 (Daniel DeLorme) 07 Mar '25

07 Mar '25

Issue #18784 has been updated by Dan0042 (Daniel DeLorme). It could also be an option like `FileUtils.rm(ignore_missing: true)`, that way it can apply to both `rm` and `rm_r`. ---------------------------------------- Feature #18784: `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exceptions https://bugs.ruby-lang.org/issues/18784#change-112215 * Author: deivid (David Rodríguez) * Status: Open ---------------------------------------- In recent times, I've been having issues with these methods because they don't let you know when some issue happened while trying to remove the given folders/files. IMO most users expect all pre-existing folders/files that are passed to these methods to be actually removed by the methods. Instead, when this happens, errors are silently swallowed and normally the result is that you will get some other issue further down the road, making the problem hard to debug. The current workaround I'm using is to double check whether the files still exist after the method, and raise a custom error if they do, but I still can't see the original problem, so issues are similarly hard to debug. This is also a deviation from how `rm -rf` and `rm -f` work, since these tools finish with a failure exit code when they fail to remove the given files. Given that `fileutils` is intended to mimic shell functionality, I think this is just a bug. I think the intention of the `force` flag here is to: * Don't prompt for confirmation. * Ignore given arguments that are not files that already exist. But any issue other than that should not be swallowed, and in general I think the method should succeed if and only if the given list of file names does not exist after the methods are done. I think this is in line with the following note I get when I run `man rm`, but also suggests that this is not the standard behavior of "historical implementations" > COMPATIBILITY > > The rm utility differs from historical implementations in that the -f option only masks attempts to remove non-existent files instead of masking a large variety of errors. I implemented this at https://github.com/ruby/fileutils/pull/58, but treating this as a bug. I can also implement a more conservative for approach for users that might be using `FileUtils.rm_rf` or `FileUtils.rm_f` but don't really care if the files are removed or not. Alternative proposals would be `FileUtils.rm_rf(force: strict)`, or `FileUtils.strict_rm_rf`, but to be honest, if this is considered a breaking change, I would ship it as a new major version, and let users update their code to swallow errors themselves if they need to. Happy to hear any feedback! -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121259] [Ruby master Feature#18784] `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exceptions
by deivid 07 Mar '25

07 Mar '25

Issue #18784 has been updated by deivid (David Rodríguez). Today I again spent a lot of time debugging an issue, and it ended up being an exception swallowed by `FileUtils.rm_rf`. Would you be ok with adding `FileUtils.rm_rf!` that mimics standard `rm -rf` shell behaviour, similar to what @Dan0042 suggested above? A new method does not pose backwards compatibility concerns, and I think the name conveys well that it's the same as `FileUtils.rm_rf` but potentially raising exceptions if deletion fails. Then it would be easy enough to add a RuboCop cop for those who prefer the more strict version to enforce `FileUtils.rm_rf!` over `FileUtils.rm_rf`. I'm happy to implement this if accepted! ---------------------------------------- Feature #18784: `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exceptions https://bugs.ruby-lang.org/issues/18784#change-112214 * Author: deivid (David Rodríguez) * Status: Open ---------------------------------------- In recent times, I've been having issues with these methods because they don't let you know when some issue happened while trying to remove the given folders/files. IMO most users expect all pre-existing folders/files that are passed to these methods to be actually removed by the methods. Instead, when this happens, errors are silently swallowed and normally the result is that you will get some other issue further down the road, making the problem hard to debug. The current workaround I'm using is to double check whether the files still exist after the method, and raise a custom error if they do, but I still can't see the original problem, so issues are similarly hard to debug. This is also a deviation from how `rm -rf` and `rm -f` work, since these tools finish with a failure exit code when they fail to remove the given files. Given that `fileutils` is intended to mimic shell functionality, I think this is just a bug. I think the intention of the `force` flag here is to: * Don't prompt for confirmation. * Ignore given arguments that are not files that already exist. But any issue other than that should not be swallowed, and in general I think the method should succeed if and only if the given list of file names does not exist after the methods are done. I think this is in line with the following note I get when I run `man rm`, but also suggests that this is not the standard behavior of "historical implementations" > COMPATIBILITY > > The rm utility differs from historical implementations in that the -f option only masks attempts to remove non-existent files instead of masking a large variety of errors. I implemented this at https://github.com/ruby/fileutils/pull/58, but treating this as a bug. I can also implement a more conservative for approach for users that might be using `FileUtils.rm_rf` or `FileUtils.rm_f` but don't really care if the files are removed or not. Alternative proposals would be `FileUtils.rm_rf(force: strict)`, or `FileUtils.strict_rm_rf`, but to be honest, if this is considered a breaking change, I would ship it as a new major version, and let users update their code to swallow errors themselves if they need to. Happy to hear any feedback! -- https://bugs.ruby-lang.org/

1 0