- ruby-core - ml.ruby-lang.org

[ruby-core:123456] [Ruby Feature#15590] Add dups to Array to find duplicates
by dpepper (Daniel Pepper) 09 Oct '25

09 Oct '25

Issue #15590 has been updated by dpepper (Daniel Pepper). I stumbled upon this thread during my own quest to find duplicates in an array. Here's a PR to create `Array#duplicates?`. If that gains any traction, maybe we could follow with `Array#duplicates` to return the actual list of duplicate elements, which seems of interest to this group. https://github.com/ruby/ruby/pull/14805 ---------------------------------------- Feature #15590: Add dups to Array to find duplicates https://bugs.ruby-lang.org/issues/15590#change-114825 * Author: xdmx (Eric Bloom) * Status: Open ---------------------------------------- Many times I find myself debugging data and the need of finding duplicated values inside of an Array. Based on the amount of data it could be a simple `array.detect { |value| array.count(value) > 1 }` or a more performant way like ```ruby def dups_for(array) duplicated_values = [] tmp = {} array.each do |value| duplicated_values << value if tmp[value] tmp[value] = true end duplicated_values end ``` It would be awesome if there was a way directly from the core language to call `dups` (or another name, as it could be too similar to the current `dup`) on an array in order to get all the duplicated values. I'd love to create a PR for this, but my C level is non-existent 😞 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123455] [Ruby Feature#7845] Strip doesn't handle unicode space characters in ruby 1.9.2 & 1.9.3 (does in 1.9.1)
by TALlama (Seth Roby) 09 Oct '25

09 Oct '25

Issue #7845 has been updated by TALlama (Seth Roby). matz (Yukihiro Matsumoto) wrote in #note-17: > That indicates the need for something like (({str.strip(:ascii)})), or opposite (({str.strip(:utf8)})) This issue has been dormant for many years, and Ruby has made a lot of changes to be use UTF-8 defaults while the world has steadily moved in that direction. Should we bring this back into consideration as a fix worth making? It certainly blindsided me, and I've been using Ruby since before this ticket was new. ---------------------------------------- Feature #7845: Strip doesn't handle unicode space characters in ruby 1.9.2 & 1.9.3 (does in 1.9.1) https://bugs.ruby-lang.org/issues/7845#change-114824 * Author: timothyg56 (Timothy Garnett) * Status: Open ---------------------------------------- Strip and associated methods in ruby 1.9.2 and 1.9.3 do not remove leading/trailing unicode space characters (such as non-breaking space \u00A0 and ideographic space \u3000) unlike ruby 1.9.1. I'd expect the 1.9.1 behavior. Looking at the underlying native lstrip! and rstrip! methods it looks like this is because 1.9.1 uses rb_enc_isspace() whereas 1.9.2+ uses rb_isspace(). 1.9.1p378 :001 > "\u3000\u00a0".strip => "" 1.9.2p320 :001 > "\u3000\u00a0".strip => "　 " 1.9.3p286 :001 > "\u3000\u00a0".strip => "　 " -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123318] [Ruby Bug#21614] thread_sched_wait_events race with timer_thread_wakeup
by luke-gru (Luke Gruber) 09 Oct '25

09 Oct '25

Issue #21614 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21614: thread_sched_wait_events race with timer_thread_wakeup https://bugs.ruby-lang.org/issues/21614 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `thread_sched_wait_events` checks th->sched.waiting_reason.flags under thread_sched_lock but not under timer_thread.waiting_lock. The timer thread sets it under the timer_thread.waiting_lock only. This race results in the assertion failure: `../ruby/thread_pthread.c:909: Assertion Failed: thread_sched_to_running_common:sched->running != th` Reproduction script (run it many times): ```ruby require "timeout" def invoke_ruby(args, stdin_data = "", capture_stdout = false, capture_stderr = false, encoding: nil, timeout: 10, reprieve: 1, timeout_error: Timeout::Error, stdout_filter: nil, stderr_filter: nil, ios: nil, signal: :TERM, rubybin: "ruby", precommand: nil, **opt) timeout = 60 in_c, in_p = IO.pipe out_p, out_c = IO.pipe if capture_stdout err_p, err_c = IO.pipe if capture_stderr && capture_stderr != :merge_to_stdout opt[:in] = in_c opt[:out] = out_c if capture_stdout opt[:err] = capture_stderr == :merge_to_stdout ? out_c : err_c if capture_stderr if encoding out_p.set_encoding(encoding) if out_p err_p.set_encoding(encoding) if err_p end ios.each {|i, o = i|opt[i] = o} if ios c = "C" child_env = {} if Array === args and Hash === args.first child_env.update(args.shift) end args = [args] if args.kind_of?(String) # use the same parser as current ruby if args.none? { |arg| arg.start_with?("--parser=") } args = ["--parser=prism"] + args end pid = spawn(child_env, *precommand, rubybin, *args, opt) in_c.close out_c&.close out_c = nil err_c&.close err_c = nil if block_given? return yield in_p, out_p, err_p, pid else th_stdout = Thread.new { out_p.read } if capture_stdout th_stderr = Thread.new { err_p.read } if capture_stderr && capture_stderr != :merge_to_stdout in_p.write stdin_data.to_str unless stdin_data.empty? in_p.close if (!th_stdout || th_stdout.join(timeout)) && (!th_stderr || th_stderr.join(timeout)) timeout_error = nil else $stderr.puts "Error: timed out" status = terminate(pid, signal, opt[:pgroup]) terminated = Time.now end stdout = th_stdout.value if capture_stdout stderr = th_stderr.value if capture_stderr && capture_stderr != :merge_to_stdout out_p.close if capture_stdout err_p.close if capture_stderr && capture_stderr != :merge_to_stdout status ||= Process.wait2(pid)[1] stdout = stdout_filter.call(stdout) if stdout_filter stderr = stderr_filter.call(stderr) if stderr_filter if timeout_error bt = caller_locations msg = "execution of #{bt.shift.label} expired timeout (#{timeout} sec)" raise timeout_error, msg, bt.map(&:to_s) end return stdout, stderr, status end ensure [th_stdout, th_stderr].each do |th| th.kill if th end [in_c, in_p, out_c, out_p, err_c, err_p].each do |io| io&.close end [th_stdout, th_stderr].each do |th| th.join if th end end def terminate(pid, signal = :TERM, pgroup = nil) case pgroup when 0, true pgroup = -pid when nil, false pgroup = pid end begin Process.kill signal, pgroup rescue Errno::EINVAL rescue Errno::ESRCH end $? end rs = [] 100.times do rs << Ractor.new do script = '$stdout.sync=true; def rec; print "."; rec; end; Fiber.new{rec}.resume' invoke_ruby([{}, '-e', script], "", true, true) end end rs.each(&:join) ``` This script is just taken directly from a failed test in the test suite that was run under multiple ractors at once (`test_vm_stack_size`). -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121389] [Ruby Bug#21187] Strings concatenated with `\` getting frozen with literal hashes (PRISM only)
by LocoDelAssembly 09 Oct '25

09 Oct '25

Issue #21187 has been reported by LocoDelAssembly (Hernán Pereira). ---------------------------------------- Bug #21187: Strings concatenated with `\` getting frozen with literal hashes (PRISM only) https://bugs.ruby-lang.org/issues/21187 * Author: LocoDelAssembly (Hernán Pereira) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When the first elements of a literal hash are strings that are concatenated with `\`, those elements are flagged with `PM_NODE_FLAG_STATIC_LITERAL` and a special optimization that I believe was introduced in https://github.com/ruby/ruby/commit/8080de04be8e99e71309745822a9d436cc4ae37c causes the strings to be frozen. Reproduction === test.rb ``` a = { a: 'one' \ 'two', b: 'three' \ 'four', c: 'five', d: 'six' \ 'seven' } b = { a: 'one', b: 'two' \ 'three' } puts "a = #{a.map { |k,v| {k => v.frozen?} }}" puts "b = #{b.map { |k,v| {k => v.frozen?} }}" ``` With prism: ``` $ ruby test.rb a = [{a: true}, {b: true}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` With parse.y: ``` $ ruby --parser=parse.y test.rb a = [{a: false}, {b: false}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` (Notice `b` hash is unaffected in both parsers) Not sure if this is just part of undefined behavior or this is indeed a bug. Assigning a string concatenated with `\` to a variable doesn't make it frozen, to the best of my knowledge this seems to be hash-specific. -- https://bugs.ruby-lang.org/

6 11

[ruby-core:123433] [Ruby Misc#21630] Suggest @Earlopain for core contributor
by kddnewton (Kevin Newton) 09 Oct '25

09 Oct '25

Issue #21630 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #21630: Suggest @Earlopain for core contributor https://bugs.ruby-lang.org/issues/21630 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- @Earlopain has been prolifically contributing to Prism for over a year, in addition to other various changes around ruby/ruby, like [96fdaf2e](https://github.com/ruby/ruby/commit/96fdaf2e393933fdd128cd1a41fa9…, [3826019f](https://github.com/ruby/ruby/commit/3826019f310991aedf0612408d7b8…, [a82e7132](https://github.com/ruby/ruby/commit/a82e7132df71bd99b5d02c0c8a348…, and [many more](https://github.com/ruby/ruby/commits/master/?author=Earlopain). I would very much like @Earlopain to be able to merge their own contributions to Ruby, since they have been of such high quality for so long. -- https://bugs.ruby-lang.org/

6 5

[ruby-core:123449] [Ruby Bug#21633] A `rb_thread_call_without_gvl` loop can cause the fiber scheduler to ignore signals.
by ioquatix (Samuel Williams) 09 Oct '25

09 Oct '25

Issue #21633 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21633: A `rb_thread_call_without_gvl` loop can cause the fiber scheduler to ignore signals. https://bugs.ruby-lang.org/issues/21633 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- The gRPC gem calls `rb_thread_call_without_gvl` in a loop, and doesn't exit when interrupts are delivered if `Thread.handle_interrupt(::SignalException => :never)` is used by the scheduler to create a safe point for asynchronous signal handling. While this may not be considered a bug in any particular part of the system, the combination of the behaviour creates a situation where gRPC can hang for a long time and ignores SIGINT / SIGTERM. ## gRPC Failure Analysis From [`src/ruby/ext/grpc/rb_completion_queue.c`](https://github.com/samuel-williams-shopify/grpc/blob/debug/src/ruby/ext/grpc/rb_completion_queue.c): ```c static void unblock_func(void* param) { next_call_stack* const next_call = (next_call_stack*)param; next_call->interrupted = 1; // ← SIGINT causes this flag to be set } grpc_event rb_completion_queue_pluck(grpc_completion_queue* queue, void* tag, gpr_timespec deadline, const char* reason) { // ... do { next_call.interrupted = 0; // ← Reset flag rb_thread_call_without_gvl(grpc_rb_completion_queue_pluck_no_gil, (void*)&next_call, unblock_func, (void*)&next_call); if (next_call.event.type != GRPC_QUEUE_TIMEOUT) break; } while (next_call.interrupted); // ← The problem! If interrupted, LOOP AGAIN! return next_call.event; } ``` The loop explicitly retries after interruption, making SIGINT/SIGTERM ineffective. This might be considered the expected behaviour if `Thread.handle_interrupt` is used. However, the goal of `Thread.handle_interrupt` in the fiber scheduler is to create a safe point for signal handling, not to prevent them completely. Since this loop never yields back to the scheduler, no such chance exists, and the loop will continue indefinitely. As `rb_thread_call_without_gvl` invokes `vm_check_ints_blocking`, one solution is to yield to the scheduler in the case that there are pending interrupts. This gives the scheduler a chance to handle the incoming SIGINT / SIGTERM signals at the safe point. For a full reproduction of the issue using gRPC: https://github.com/samuel-williams-shopify/grpc-interrupt For the proposed fix: https://github.com/ruby/ruby/pull/14700 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123446] [Ruby Bug#21632] Backport REXML CVE-2025-58767 fix
by Bo98 (Bo Anderson) 09 Oct '25

09 Oct '25

Issue #21632 has been reported by Bo98 (Bo Anderson). ---------------------------------------- Bug #21632: Backport REXML CVE-2025-58767 fix https://bugs.ruby-lang.org/issues/21632 * Author: Bo98 (Bo Anderson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Even though it's a bundled gem and not a default gem, it would be worthwhile backporting the fix for CVE-2025-58767 (https://www.ruby-lang.org/en/news/2025/09/18/dos-rexml-cve-2025-58767/) Ruby 3.4 PR: https://github.com/ruby/ruby/pull/14795 Ruby 3.3 PR: https://github.com/ruby/ruby/pull/14796 I'm not sure what to do for Ruby 3.2. It's a security fix so it qualifies for a backport, but there's other changes included in a version bump. Do we need a rexml 3.3.9.1? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123399] [Ruby Bug#21626] Backport WASI setjmp handler memory leak fixes
by white-axe (Hao Liu) 09 Oct '25

09 Oct '25

Issue #21626 has been reported by white-axe (Hao Liu). ---------------------------------------- Bug #21626: Backport WASI setjmp handler memory leak fixes https://bugs.ruby-lang.org/issues/21626 * Author: white-axe (Hao Liu) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The WASI builds of Ruby 3.2, 3.3 and 3.4 currently have bugs in the handling of setjmp/longjmp that cause memory leaks. In Ruby 3.2, 3.3 and 3.4, there is a bug where the stack pointer is sometimes not reset after a longjmp, leading to leaking of part of the stack and the garbage collector being unable to garbage collect some Ruby objects since the garbage collector looks for GC roots on the stack. In Ruby 3.3 and 3.4, https://github.com/ruby/ruby/pull/8902 caused a second bug where setjmp buffers are not freed after a longjmp. The combination of these two bugs causes the WASI builds of Ruby 3.3 and 3.4 to very rapidly run out of memory when running this script. The memory leak is much less noticeable in the WASI build of Ruby 3.2. ```ruby loop do array = [0] for item in array break end end ``` To test it out, save this script as test.rb in the current working directory and then run these commands. This tests the WASI build of Ruby 3.4, but you can change the "3.4" to "3.3" to test out the build for Ruby 3.3. If you use the Ruby 3.5 build instead by replacing "3.4" with "head", it will not crash anymore. ``` curl -Lo ruby.tar.gz https://github.com/ruby/ruby.wasm/releases/download/2.7.2/ruby-3.4-wasm32-u… tar xzf ruby.tar.gz --strip-components=1 wasmtime --dir .::/ usr/local/bin/ruby test.rb ``` These two bugs should have been fixed in Ruby 3.5 by https://github.com/ruby/ruby/pull/12995, but the fix contained bugs that were later amended by https://github.com/ruby/ruby/pull/13026 and https://github.com/ruby/ruby/pull/13142. I'm requesting for the changes from all three of these pull requests to be backported to Ruby 3.2, 3.3 and 3.4, which could be done with the patch below. For Ruby 3.2, only the changes to wasm/setjmp.c and wasm/setjmp.h are required because the other changes are only to fix the second bug. ```patch --- a/cont.c +++ b/cont.c @@ -1509,6 +1509,51 @@ cont_restore_thread(rb_context_t *cont) rb_raise(rb_eRuntimeError, "can't call across trace_func"); } +#if defined(__wasm__) && !defined(__EMSCRIPTEN__) + if (th->ec->tag != sec->tag) { + /* find the lowest common ancestor tag of the current EC and the saved EC */ + + struct rb_vm_tag *lowest_common_ancestor = NULL; + size_t num_tags = 0; + size_t num_saved_tags = 0; + for (struct rb_vm_tag *tag = th->ec->tag; tag != NULL; tag = tag->prev) { + ++num_tags; + } + for (struct rb_vm_tag *tag = sec->tag; tag != NULL; tag = tag->prev) { + ++num_saved_tags; + } + + size_t min_tags = num_tags <= num_saved_tags ? num_tags : num_saved_tags; + + struct rb_vm_tag *tag = th->ec->tag; + while (num_tags > min_tags) { + tag = tag->prev; + --num_tags; + } + + struct rb_vm_tag *saved_tag = sec->tag; + while (num_saved_tags > min_tags) { + saved_tag = saved_tag->prev; + --num_saved_tags; + } + + while (min_tags > 0) { + if (tag == saved_tag) { + lowest_common_ancestor = tag; + break; + } + tag = tag->prev; + saved_tag = saved_tag->prev; + --min_tags; + } + + /* free all the jump buffers between the current EC's tag and the lowest common ancestor tag */ + for (struct rb_vm_tag *tag = th->ec->tag; tag != lowest_common_ancestor; tag = tag->prev) { + rb_vm_tag_jmpbuf_deinit(&tag->buf); + } + } +#endif + /* copy vm stack */ #ifdef CAPTURE_JUST_VALID_VM_STACK MEMCPY(th->ec->vm_stack, --- a/signal.c +++ b/signal.c @@ -854,6 +854,7 @@ check_stack_overflow(int sig, const uintptr_t addr, const ucontext_t *ctx) * otherwise it can cause stack overflow again at the same * place. */ if ((crit = (!ec->tag->prev || !--uplevel)) != FALSE) break; + rb_vm_tag_jmpbuf_deinit(&ec->tag->buf); ec->tag = ec->tag->prev; } reset_sigmask(sig); --- a/vm.c +++ b/vm.c @@ -2829,6 +2829,7 @@ vm_exec_handle_exception(rb_execution_context_t *ec, enum ruby_tag_type state, V if (VM_FRAME_FINISHED_P(ec->cfp)) { rb_vm_pop_frame(ec); ec->errinfo = (VALUE)err; + rb_vm_tag_jmpbuf_deinit(&ec->tag->buf); ec->tag = ec->tag->prev; EC_JUMP_TAG(ec, state); } --- a/vm_trace.c +++ b/vm_trace.c @@ -455,6 +455,7 @@ rb_exec_event_hooks(rb_trace_arg_t *trace_arg, rb_hook_list_t *hooks, int pop_p) if (state) { if (pop_p) { if (VM_FRAME_FINISHED_P(ec->cfp)) { + rb_vm_tag_jmpbuf_deinit(&ec->tag->buf); ec->tag = ec->tag->prev; } rb_vm_pop_frame(ec); --- a/wasm/setjmp.c +++ b/wasm/setjmp.c @@ -143,9 +143,11 @@ rb_wasm_try_catch_init(struct rb_wasm_try_catch *try_catch, try_catch->try_f = try_f; try_catch->catch_f = catch_f; try_catch->context = context; + try_catch->stack_pointer = NULL; } // NOTE: This function is not processed by Asyncify due to a call of asyncify_stop_rewind +__attribute__((noinline)) void rb_wasm_try_catch_loop_run(struct rb_wasm_try_catch *try_catch, rb_wasm_jmp_buf *target) { @@ -154,6 +156,10 @@ rb_wasm_try_catch_loop_run(struct rb_wasm_try_catch *try_catch, rb_wasm_jmp_buf target->state = JMP_BUF_STATE_CAPTURED; + if (try_catch->stack_pointer == NULL) { + try_catch->stack_pointer = rb_wasm_get_stack_pointer(); + } + switch ((enum try_catch_phase)try_catch->state) { case TRY_CATCH_PHASE_MAIN: // may unwind @@ -175,6 +181,8 @@ rb_wasm_try_catch_loop_run(struct rb_wasm_try_catch *try_catch, rb_wasm_jmp_buf // stop unwinding // (but call stop_rewind to update the asyncify state to "normal" from "unwind") asyncify_stop_rewind(); + // reset the stack pointer to what it was before the most recent call to try_f or catch_f + rb_wasm_set_stack_pointer(try_catch->stack_pointer); // clear the active jmpbuf because it's already stopped _rb_wasm_active_jmpbuf = NULL; // reset jmpbuf state to be able to unwind again --- a/wasm/setjmp.h +++ b/wasm/setjmp.h @@ -65,6 +65,7 @@ struct rb_wasm_try_catch { rb_wasm_try_catch_func_t try_f; rb_wasm_try_catch_func_t catch_f; void *context; + void *stack_pointer; int state; }; ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123405] [Ruby Misc#21628] Sync default gems to ruby/ruby with GitHub Actions
by k0kubun (Takashi Kokubun) 09 Oct '25

09 Oct '25

Issue #21628 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Misc #21628: Sync default gems to ruby/ruby with GitHub Actions https://bugs.ruby-lang.org/issues/21628 * Author: k0kubun (Takashi Kokubun) * Status: Open ---------------------------------------- ## Announcement We will change the way default gems are synchronized to ruby/ruby. * **Before**: Push to gem repository → webhook.cgi → git.ruby-lang.org pushes to ruby/ruby * **After**: Push to gem repository → GitHub Actions on gem repository → GitHub Actions on ruby/ruby pushes to ruby/ruby ## Background * The apache2 server for https://git.ruby-lang.org has been taken down because it has been under DDoS attacks and we couldn't handle it. As a result, its webhook.cgi is no longer online. * It was hard for default gem maintainers to notice sync failures, look at their logs, and fix them. * Moving the implementation to GitHub Actions would make them more visible and accessible for the maintainers. ## Operations To set up sync from ruby/xxx to ruby/ruby, you need to do the following operations: 1. [Optional] Remove `https://git.ruby-lang.org/webhook` from Settings > Webhooks if it's currently set. 2. On Settings > Secrets and variables > Actions > Organization secrets, make sure the repository has access to `RUBY_SYNC_DEFAULT_GEMS_PRIVATE_KEY` * Consult @hsbt if it's not visible for the repository. "ruby-sync-default-gems GitHub App Private Key" is managed under the "Ruby core team" 1Password vault. 3. Add a GitHub Actions workflow list this [.github/workflows/sync-ruby.yml](https://github.com/ruby/erb/blob/v5.0.3/.github/workflows/sync-ruby.yml) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123414] [Ruby Bug#21629] Ruby-3.4.7 fails to build using clang / llvm
by debo (David Bohman) 08 Oct '25

08 Oct '25

Issue #21629 has been reported by debo (David Bohman). ---------------------------------------- Bug #21629: Ruby-3.4.7 fails to build using clang / llvm https://bugs.ruby-lang.org/issues/21629 * Author: debo (David Bohman) * Status: Open * ruby -v: ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [x86_64-darwin16] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Here is the error I encountered. This is using clang version 21.1.3 as the compiler toolchain on Darwin. ``` DYLD_LIBRARY_PATH=.:../../.. ASAN_OPTIONS=detect_leaks=0 "clang -I../../../.ext/include/x86_64-darwin16 -I../../../../ruby-3.4.7/include -I../../../../ruby-3.4.7/ext/-test-/public_header_warnings -I/usr/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wextra-tokens -Wdeprecated-declarations -Wdivision-by-zero -Wdiv-by-zero -Wimplicit-function-declaration -Wimplicit-int -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 -Wmisleading-indentation -Wundef -fno-common -pipe -D_TEST_OK -Werror -c conftest.c" In file included from conftest.c:1: In file included from ../../../../ruby-3.4.7/include/ruby.h:38: In file included from ../../../../ruby-3.4.7/include/ruby/ruby.h:28: In file included from ../../../../ruby-3.4.7/include/ruby/internal/arithmetic.h:24: In file included from ../../../../ruby-3.4.7/include/ruby/internal/arithmetic/char.h:29: ../../../../ruby-3.4.7/include/ruby/internal/core/rstring.h:398:24: error: default initialization of an object of type 'struct RString' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe] 398 | struct RString retval; | ^ ../../../../ruby-3.4.7/include/ruby/internal/core/rbasic.h:86:17: note: member 'klass' declared 'const' here 86 | const VALUE klass; | ^ 1 error generated. checked program was: /* begin */ 1: #include "ruby.h" 2: 3: int main(int argc, char **argv) 4: { 5: return !!argv[argc]; 6: } /* end */ ``` The configuration is the following: ``` CC=clang CXX=clang++ CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ../ruby-3.4.7/configure --enable-shared --with-rdoc=ri,html ``` -- https://bugs.ruby-lang.org/

4 17