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

[ruby-core:113507] [Ruby master Bug#19677] Failed to build ruby from the source code when following the guide
by tagomoris (Satoshi TAGOMORI) 17 May '23

17 May '23

Issue #19677 has been reported by tagomoris (Satoshi TAGOMORI). ---------------------------------------- Bug #19677: Failed to build ruby from the source code when following the guide https://bugs.ruby-lang.org/issues/19677 * Author: tagomoris (Satoshi TAGOMORI) * Status: Open * Priority: Normal * ruby -v: git clone github.com/ruby/ruby (master HEAD cea9c30fa549885e36471f1782359df2bdcf895a) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I followed the document "Building Ruby" (doc/contributing/building_ruby.md) and got build errors. At the step of "5. Build Ruby: make install", the errors below happened: ``` MBA:build tagomoris$ make -j 8 BASERUBY = /Users/tagomoris/.rbenv/shims/ruby --disable=gems CC = clang LD = ld LDSHARED = clang -dynamiclib CFLAGS = -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wextra-tokens -Wdeprecated-declarations -Wdivision-by-zero -Wdiv-by-zero -Wimplicit-function-declaration -Wimplicit-int -Wmisleading-indentation -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wold-style-definition -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wunused-variable -Wundef -pipe XCFLAGS = -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -DRUBY_EXPORT -fPIE -I. -I.ext/include/arm64-darwin22 -I../include -I.. -I../enc/unicode/15.0.0 CPPFLAGS = -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT DLDFLAGS = -L/opt/homebrew/opt/bison/lib -Wl,-multiply_defined,suppress -Wl,-undefined,dynamic_lookup -fstack-protector-strong -Wl,-pie -framework CoreFoundation SOLIBS = -ldl -lobjc -lpthread LANG = LC_ALL = LC_CTYPE = UTF-8 MFLAGS = - --jobserver-fds=4,5 -j RUSTC = rustc YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/Users/tagomoris/gh/ruby/build/yjit/target/release/' ../yjit/src/lib.rs Apple clang version 14.0.3 (clang-1403.0.22.14.1) Target: arm64-apple-darwin22.4.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin compiling ../compile.c compiling ../complex.c compiling ../cont.c compiling ../debug.c compiling ../debug_counter.c compiling ../dir.c compiling ../dln_find.c compiling ../encoding.c compiling ../enum.c compiling ../enumerator.c making ../warning.rbinc ../compile.c:2455:38: error: call to undeclared function 'ISEQ_IS_ENTRY_START'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] IC ic = &ISEQ_IS_ENTRY_START(body, type)[ic_index].ic_cache; ^ ../compile.c:2455:69: error: subscripted value is not an array, pointer, or vector IC ic = &ISEQ_IS_ENTRY_START(body, type)[ic_index].ic_cache; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~ ../compile.c:2484:28: error: use of undeclared identifier 'TS_ICVARC'; did you mean 'TS_IVC'? case TS_ICVARC: /* inline cvar cache */ ^~~~~~~~~ TS_IVC ../insns_info.inc:44:5: note: 'TS_IVC' declared here TS_IVC = 'A', ^ (snip) ``` I got a successful build when I tried `make ruby; make install` instead. So, I'm assuming that the build script has a bug, or the document should be updated. My environment summary: ``` $ uname -a Darwin Moris-Air 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar 6 21:00:41 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T8103 arm64 $ clang --version Apple clang version 14.0.3 (clang-1403.0.22.14.1) Target: arm64-apple-darwin22.4.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:113505] [Ruby master Feature#12165] Hash#first, Hash#last
by bughit (bug hit) 17 May '23

17 May '23

Issue #12165 has been updated by bughit (bug hit). nobu (Nobuyoshi Nakada) wrote in #note-5: > Although I've not thought about `Hash#last`, once when `st_table` got keeping the insertion order I proposed `Hash#reverse_each` (`st_reverse_foreach` for it precisely) to matz, but was rejected. Is it not reasonable for a user to expect that core/std lib code will be at least not, knowingly, intentionally, horribly sub-optimal? Since at least two people tried to fix `Hash#reverse_each` and were rejected, that's exactly what it is at this point, knowingly, intentionally, horribly sub-optimal. ---------------------------------------- Feature #12165: Hash#first, Hash#last https://bugs.ruby-lang.org/issues/12165#change-103100 * Author: stillhart (Fabian Stillhart) * Status: Open * Priority: Normal ---------------------------------------- Just run into a simple problem with a colleague and was wondering why there is no Hash#last method? ~~~ruby {a: true, b: false}.last NoMethodError: undefined method 'last' for {:a=>true, :b=>false}:Hash ~~~ Interestingly I while playing arround I found out that the Hash#first method works. But why is it not in the ruby-doc? ~~~ruby {a: true, b: false}.first => [:a, true] ~~~ I would assume the Hash#last method would work like the Hash#first method: ~~~ruby {a: true, b: false}.last => [:b, false] ~~~ If I am not wrong the order of a Hash is always the same when calling Hash#each. So wouldn't it make sense to have Hash#last method? I tested it in Ruby 2.2.4 and Ruby 2.3.0. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113501] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by nobu (Nobuyoshi Nakada) 16 May '23

16 May '23

Issue #18743 has been updated by nobu (Nobuyoshi Nakada). Seems find to me. One thing I concerned, `stop_exc` will be re-created every times, and no way to know where it was first used up. How about chaining by `cause`? ```diff diff --git a/enumerator.c b/enumerator.c index b33c1713718..1cc8f9108cf 100644 --- a/enumerator.c +++ b/enumerator.c @@ -30,6 +30,9 @@ #include "internal/rational.h" #include "ruby/ruby.h" +extern ID ruby_static_id_cause; +#define id_cause ruby_static_id_cause + /* * Document-class: Enumerator * @@ -787,8 +790,16 @@ get_next_values(VALUE obj, struct enumerator *e) { VALUE curr, vs; - if (e->stop_exc) - rb_exc_raise(e->stop_exc); + if (e->stop_exc) { + VALUE exc = e->stop_exc; + VALUE result = rb_attr_get(exc, id_result); + VALUE mesg = rb_attr_get(exc, idMesg); + if (!NIL_P(mesg)) mesg = rb_str_dup(mesg); + VALUE stop_exc = rb_exc_new_str(rb_eStopIteration, mesg); + rb_ivar_set(stop_exc, id_result, result); + rb_ivar_set(stop_exc, id_cause, exc); + rb_exc_raise(stop_exc); + } curr = rb_fiber_current(); ``` In the test, save `$!` at the first `rescue` then `assert_same(cause, exc.cause)`. ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-103096 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113500] [Ruby master Feature#12165] Hash#first, Hash#last
by nobu (Nobuyoshi Nakada) 16 May '23

16 May '23

Issue #12165 has been updated by nobu (Nobuyoshi Nakada). Although I've not thought about `Hash#last`, once when `st_table` got keeping the insertion order I proposed `Hash#reverse_each` (`st_reverse_foreach` for it precisely) to matz, but was rejected. ---------------------------------------- Feature #12165: Hash#first, Hash#last https://bugs.ruby-lang.org/issues/12165#change-103095 * Author: stillhart (Fabian Stillhart) * Status: Open * Priority: Normal ---------------------------------------- Just run into a simple problem with a colleague and was wondering why there is no Hash#last method? ~~~ruby {a: true, b: false}.last NoMethodError: undefined method 'last' for {:a=>true, :b=>false}:Hash ~~~ Interestingly I while playing arround I found out that the Hash#first method works. But why is it not in the ruby-doc? ~~~ruby {a: true, b: false}.first => [:a, true] ~~~ I would assume the Hash#last method would work like the Hash#first method: ~~~ruby {a: true, b: false}.last => [:b, false] ~~~ If I am not wrong the order of a Hash is always the same when calling Hash#each. So wouldn't it make sense to have Hash#last method? I tested it in Ruby 2.2.4 and Ruby 2.3.0. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113499] [Ruby master Feature#12165] Hash#first, Hash#last
by bughit (bug hit) 16 May '23

16 May '23

Issue #12165 has been updated by bughit (bug hit). @nobu Since you commented recently, what do you think about about a performant Hash#last(n=1) and a related performant Hash#reverse_each ? Should any ordered collection have those? ---------------------------------------- Feature #12165: Hash#first, Hash#last https://bugs.ruby-lang.org/issues/12165#change-103094 * Author: stillhart (Fabian Stillhart) * Status: Open * Priority: Normal ---------------------------------------- Just run into a simple problem with a colleague and was wondering why there is no Hash#last method? ~~~ruby {a: true, b: false}.last NoMethodError: undefined method 'last' for {:a=>true, :b=>false}:Hash ~~~ Interestingly I while playing arround I found out that the Hash#first method works. But why is it not in the ruby-doc? ~~~ruby {a: true, b: false}.first => [:a, true] ~~~ I would assume the Hash#last method would work like the Hash#first method: ~~~ruby {a: true, b: false}.last => [:b, false] ~~~ If I am not wrong the order of a Hash is always the same when calling Hash#each. So wouldn't it make sense to have Hash#last method? I tested it in Ruby 2.2.4 and Ruby 2.3.0. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113497] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by marcper (Marcelo Pereira) 16 May '23

16 May '23

Issue #18743 has been updated by marcper (Marcelo Pereira). Hey again, @ko1. This is just a reminder that the patch is pushed to Github and is waiting for a decision. Best, Marcelo ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-103093 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113494] [Ruby master Bug#11582] On Solaris, Rational#** returns -Infinity for Rational(0) when passed a negative Float
by ngoto (Naohisa Goto) 15 May '23

15 May '23

Issue #11582 has been updated by ngoto (Naohisa Goto). Status changed from Third Party's Issue to Closed This issue is solved by [Misc #15347]. In the C99 spec, The behavior of pow(3) in corner cases are clearly defined. Since Ruby 2.7, C99 is required to compile CRuby source code, and thus Ruby's pow method conforms to the C99 standard. ---------------------------------------- Bug #11582: On Solaris, Rational#** returns -Infinity for Rational(0) when passed a negative Float https://bugs.ruby-lang.org/issues/11582#change-103079 * Author: Eregon (Benoit Daloze) * Status: Closed * Priority: Normal * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- For instance, > Rational(0, 1) ** -1.0 => +Infinity on most platforms, -Infinity on Solaris by default. The Rational is implicitly converted to the Float value 0.0, and the libm function pow(0.0, -1.0) is called. Should this kind of behavior be made consistent by Ruby or should we accept this as dependent on the libm/libc used? They are likely other edges cases for pow() which might differ, and I think in general Ruby should try to unify these cases so the behavior is consistent across platforms at least for arithmetic. For more details, please see https://github.com/ruby/rubyspec/issues/134 reported by ngoto. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113492] Storage Notice: Your mailbox is full
by ruby-core＠ml.ruby-lang.org 15 May '23

15 May '23

1 0

[ruby-core:113288] [Ruby master Misc#19608] Being a co-maintainer of the ruby/openssl for the OpenSSL FIPS mode
by jaruga (Jun Aruga) 15 May '23

15 May '23

Issue #19608 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #19608: Being a co-maintainer of the ruby/openssl for the OpenSSL FIPS mode https://bugs.ruby-lang.org/issues/19608 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal ---------------------------------------- ## Motivation and context Recently I have been working for the [ruby/openssl](https://github.com/ruby/openssl) to support OpenSSL 3 FIPS mode such as sending pull-requests and reporting issues to the [OpenSSL project](https://github.com/openssl/openssl). The related issue ticket is [here](https://github.com/ruby/openssl/issues/603). Currently a challenge of the ruby/openssl is that it doesn't work well on the OpenSSL FIPS mode, and I want ruby/openssl to work on it by adding the OpenSSL 3 FIPS mode case to the CI, and by adding more FIPS related unit tests and features. To solve this challenge, I would like to be a co-maintainer of the ruby/openssl for the FIPS mode related things. What do you think? ## What is FIPS mode? For someone who is interested in knowing the FIPS mode. Let me share the related documents below. In my understanding, FIPS mode is a security policy developed by US government. In some cases, the shipped Linux OS systems need to follow this policy. FIPS related documents: * [FIPS Wikipedia](https://en.wikipedia.org/wiki/Federal_Information_Processing_Sta… * [RHEL](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linu… * [Amazon Linux](https://aws.amazon.com/blogs/publicsector/enabling-fips-mode-amazon-… * [SUSE Linux](https://www.suse.com/support/kb/doc/?id=000019432) * [Ubuntu](https://ubuntu.com/security/certifications/docs/fips) And OpenSSL has a feature to enable the FIPS mode. The README is [here](https://github.com/openssl/openssl/blob/master/README-FIPS.md). And there can be FIPS specific issues in the ruby/openssl with the OpenSSL FIPS mode enabled. ## Past FIPS related issue tickets As a reference, I just found some old issue tickets below. It is about OpenSSL 1.0 and 1.1 FIPS mode. * https://bugs.ruby-lang.org/issues/6946 * https://bugs.ruby-lang.org/issues/19073 -- https://bugs.ruby-lang.org/

2 5

[ruby-core:113449] [Ruby master Bug#19635] errno may be overwritten by rb_sprintf if it triggers GC
by wks (Kunshan Wang) 15 May '23

15 May '23

Issue #19635 has been reported by wks (Kunshan Wang). ---------------------------------------- Bug #19635: errno may be overwritten by rb_sprintf if it triggers GC https://bugs.ruby-lang.org/issues/19635 * Author: wks (Kunshan Wang) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Here is an excerpt in the `trap` function in `signal.c` ``` c oldfunc = ruby_signal(sig, func); if (oldfunc == SIG_ERR) rb_sys_fail_str(rb_signo2signm(sig)); ``` `ruby_signal` tries to register a signal handling function. If it fails, it returns `SIG_ERR`, and `errno` is set to by `sigaction` to indicate the error. However, the snippet above calls `rb_signo2signm(sig)` before calling `rb_sys_fail_str`. `rb_signo2signm` allocates a Ruby heap object using `rb_sprintf`. The problem is, **if this `rb_sprintf` triggers GC**, the garbage collector may perform may complex operations, including executing `obj_free`, calling `mmap` to allocate more memory from the OS, etc. They **may overwrite the `errno`**. So if GC is triggered in the very unfortunate time, the caller of the `trap` function will receive an exception, but with the wrong reason. This may cause some tests, such as the `test_trap_uncatchable_#{sig}` test cases in `test_signal.rb`, to fail. There are similar use cases in `hash.c`, for example: ```c if (ret) rb_sys_fail_str(rb_sprintf("setenv(%s)", name)); ``` The good practice is always loading from `errno` immediately after calling functions that may set `errno`, such as `sigaction` and `setenv`. -- https://bugs.ruby-lang.org/

2 2