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

[ruby-core:115760] [Ruby master Bug#20068] Strings equality doesn't imply hash equality
by glebpom (Gleb Pomykalov) 16 Dec '23

16 Dec '23

Issue #20068 has been reported by glebpom (Gleb Pomykalov). ---------------------------------------- Bug #20068: Strings equality doesn't imply hash equality https://bugs.ruby-lang.org/issues/20068 * Author: glebpom (Gleb Pomykalov) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It is well-known that the equality of two objects should lead to the equality of their' hashes (https://ruby-doc.org/3.2.2/Object.html#method-i-hash) Empty strings, where one encoding is not ASCII-compatible (UTF-16 in the following example), and another is ASCII-compatible don't follow this rule: ``` irb(main):038:0> l = "" => "" irb(main):039:0> r = l.encode('UTF-16LE') => "" irb(main):040:0> l.hash => 1212370190964414646 irb(main):041:0> r.hash => 1212370190964414642 irb(main):042:0> l.hash == r.hash => false irb(main):043:0> l.eql?(r) => true irb(main):044:0> l => "" irb(main):045:0> r => "" irb(main):046:0> [l,r].uniq => ["", ""] ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115759] [Ruby master Feature#18083] Capture error in ensure block.
by Dan0042 (Daniel DeLorme) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by Dan0042 (Daniel DeLorme). > Giving `$!` dynamic scope mitigates the problem but still seems to encourage an approach that @matz has said he was against. Specifically, he was against `ensure => exception` and this is just a variant of that approach. I believe Matz said he was against adding extra **syntax**, and that he was open to experimenting with ko1's proposal. Giving $! dynamic scope is indeed likely to cause subtle bugs, just less than currently. I think that almost all code currently written with `$!` in the ensure clause assume the exception is triggered within the same begin-end block. Using a dynamic scope would "magically" fix all of this currently-incorrect code. So it's a net win. And considering backwards compatibility I think it's unrealistic to consider deprecation. `$!` is used fairly often in gems. I also use it fairly often in my code, usually in some variants of the form `expr rescue $!` ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105697 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115757] [Ruby master Feature#18083] Capture error in ensure block.
by ioquatix (Samuel Williams) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by ioquatix (Samuel Williams). Giving `$!` dynamic scope is equally likely to cause subtle bugs, so no matter what we do here, there is a chance to cause compatibility issues. Deprecation is explicit and gives people a chance to fix the code, which in most cases that I reviewed, is buggy. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105695 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115756] [Ruby master Feature#18083] Capture error in ensure block.
by jeremyevans0 (Jeremy Evans) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by jeremyevans0 (Jeremy Evans). ioquatix (Samuel Williams) wrote in #note-29: > In the first instance, the question we need to answer is: "Is there a valid use case for $! (assuming dynamic scope as proposed) that isn't better addressed using existing techniques?". > > If the answer is YES, we should implement it. > > If the answer is NO, we should deprecate and remove `$!`. This perspective ignores backwards compatibility. If the answer is NO, we would still need to determine if the benefit of removing `$!` exceeds the cost of the loss of backwards compatibility. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105694 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115755] [Ruby master Feature#18083] Capture error in ensure block.
by ioquatix (Samuel Williams) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by ioquatix (Samuel Williams). `$!` is non-trivial to implement - can have performance implications, and dynamic scope might make it more expensive. cc @Eregon @headius can we get your input? Giving `$!` dynamic scope mitigates the problem but still seems to encourage an approach that @matz has said he was against. Specifically, he was against `ensure => exception` and this is just a variant of that approach. In the first instance, the question we need to answer is: "Is there a valid use case for $! (assuming dynamic scope as proposed) that isn't better addressed using existing techniques?". If the answer is YES, we should implement it. If the answer is NO, we should deprecate and remove `$!`. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105693 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115752] [Ruby master Feature#18083] Capture error in ensure block.
by Dan0042 (Daniel DeLorme) 15 Dec '23

15 Dec '23

Issue #18083 has been updated by Dan0042 (Daniel DeLorme). ko1 (Koichi Sasada) wrote in #note-20: > my proposal is introducing dynamic scope, not syntactical scope like: I think this is a good idea, definitely an improvement over the current situation. `$!` is already always correct inside a `rescue` clause, and that would make it always correct inside the `ensure` clause. But I want to confirm if this would be the expected behavior: ```ruby #1 p $! #=> A begin # no raise ensure p $! #=> nil (unlike A currently) end p $! #=> A (restored after previous begin-ensure block?) #2 p $! #=> A begin raise "B" rescue p $! #=> B #not re-raised ensure p $! #=> B (unlike A currently) end p $! #=> A (restored after previous begin-ensure block?) ``` ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105683 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115748] [Ruby master Feature#18083] Capture error in ensure block.
by kddnewton (Kevin Newton) 14 Dec '23

14 Dec '23

Issue #18083 has been updated by kddnewton (Kevin Newton). If you're already using global variables, we could add another global variable that gets set in `ensure` blocks that determines if an error was raised. That way you could safely check `$!`. That wouldn't require a syntax change. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105680 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115747] [Ruby master Feature#18083] Capture error in ensure block.
by ioquatix (Samuel Williams) 14 Dec '23

14 Dec '23

Issue #18083 has been updated by ioquatix (Samuel Williams). Here is a good example of why `$!` is dangerous: https://github.com/ruby/net-ftp/pull/24 I believe the merged fix is also wrong, since flow control can exit without closing the connection. ---------------------------------------- Feature #18083: Capture error in ensure block. https://bugs.ruby-lang.org/issues/18083#change-105679 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases. As a general model, something like the following would be incredibly useful: ``` ruby begin ... ensure => error pp "error occurred" if error end ``` Currently you can get similar behaviour like this: ``` ruby begin ... rescue Exception => error raise ensure pp "error occurred" if error end ``` The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it. Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115739] Ruby 3.2.2 Solaris-Sparc Compilation Error in iseq.c
by Jay Mav 14 Dec '23

14 Dec '23

Hello, Building Ruby 3.2.2 on Solaris-Sparc 32-bit with Developer Studio 12.6. Issues: 1) compilation of iseq.c fails due to variable definition in macro OPTION: #define SET_COMPILE_OPTION(o, h, mem) \ { VALUE flag = rb_hash_aref((h), ID2SYM(rb_intern(#mem))); \ if (flag == Qtrue) { (o)->mem = 1; } \ else if (flag == Qfalse) { (o)->mem = 0; } \ } SET_COMPILE_OPTION(option, opt, inline_const_cache); SET_COMPILE_OPTION(option, opt, peephole_optimization); SET_COMPILE_OPTION(option, opt, tailcall_optimization); SET_COMPILE_OPTION(option, opt, specialized_instruction); SET_COMPILE_OPTION(option, opt, operands_unification); SET_COMPILE_OPTION(option, opt, instructions_unification); SET_COMPILE_OPTION(option, opt, stack_caching); SET_COMPILE_OPTION(option, opt, frozen_string_literal); SET_COMPILE_OPTION(option, opt, debug_frozen_string_literal); SET_COMPILE_OPTION(option, opt, coverage_enabled); "iseq.c", line 812: identifier redefined: flag current : unsigned long ... If the definition of flag is moved outside of the macro: VALUE flag; #define SET_COMPILE_OPTION(o, h, mem) \ { flag = rb_hash_aref((h), ID2SYM(rb_intern(#mem))); \ if (flag == Qtrue) { (o)->mem = 1; } \ else if (flag == Qfalse) { (o)->mem = 0; } \ } then iseq.c gets compiled. What's the correct fix for this macro? 2) After fixing the above error, the build progresses but fails in linking miniruby linking miniruby Undefined first referenced symbol in file .L13046 iseq.o It is not clear what .L13046 represents. Can any one please share how this issue can be resolved? Thanks.

2 1

[ruby-core:115710] [Ruby master Bug#20060] bundled_gems.rb is not working with Bootsnap
by hsbt (Hiroshi SHIBATA) 13 Dec '23

13 Dec '23

Issue #20060 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20060: bundled_gems.rb is not working with Bootsnap https://bugs.ruby-lang.org/issues/20060 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Addressed from https://github.com/ruby/ruby/pull/9163#issuecomment-1850924893 `bundled_gems.rb` of 3.3.0-rc1 couldn't handle full paths by Bootsnap. ``` $ rails new example (snip) rails importmap:install bin/rails aborted! ArgumentError: comparison of String with nil failed (ArgumentError) msg = " #{RUBY_VERSION < SINCE[gem] ? "will no longer be" : "is not"} part of the default gems since Ruby #{SINCE[gem]}." (snip) ``` It's working with DISABLE_BOOTSNAP=1. But we should resolve it with under the bootsnap. -- https://bugs.ruby-lang.org/

1 3