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

[ruby-core:126211] [Ruby Feature#22222] Expose a C API equivalent of `RubyVM::InstructionSequence.load_from_binary`
by byroot (Jean Boussier) 06 Aug '26

06 Aug '26

Issue #22222 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22222: Expose a C API equivalent of `RubyVM::InstructionSequence.load_from_binary` https://bugs.ruby-lang.org/issues/22222 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Currently the only API to deserialize instruction sequence is `RubyVM::InstructionSequence.load_from_binary(String)`. It works fine, but isn't ideal for gems like bootsnap, as it needs to allocate a fairly large string and `memcpy` into it. I would like to be able to directly pass a `char *ptr` and `size_t len` pair, so that I can directly pass a internal buffer or even mmapped file. Proposed API: ``` VALUE rb_iseq_load_from_binary(const char *ptr, size_t len) ``` -- https://bugs.ruby-lang.org/

4 6

[ruby-core:126092] [Ruby Bug#22197] Backtraces show methods which do not exist
by Eregon (Benoit Daloze) 06 Aug '26

06 Aug '26

Issue #22197 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22197: Backtraces show methods which do not exist https://bugs.ruby-lang.org/issues/22197 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [arm64-darwin25] * Backport: 3.3: DONTNEED, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby class Parent def original puts caller_locations(0), nil end end class Child < Parent alias_method :alias, :original end Child.new.alias module Original def original puts caller_locations(0) end end class A define_method(:a, Original.instance_method(:original)) end A.new.a ``` gives: ``` $ ruby -v backtrace_alias.rb ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [arm64-darwin25] backtrace_alias.rb:3:in 'Child#original' backtrace_alias.rb:11:in '<main>' backtrace_alias.rb:15:in 'A#original' backtrace_alias.rb:23:in '<main>' ``` But this seems clearly incorrect: * there is no `Child#original`, there is only `Parent#original` and `Child#alias`. * there is no `A#original`, there is only `Original#original` and `A#a`. This behavior exists since Ruby 3.4 which added the module name in backtraces (#19117). So the issue is that backtraces show the "original method name from the definition" with the "method owner of the actually-called method". It should be consistent to avoid showing methods which don't exist. And it should be the original method from the definition, because we show the file and line of that, so we should also show the original name (already the case) and the original module (not the case yet, the bug). FWIW TruffleRuby already behaves like that: ``` $ truffleruby 34.0.1 (2026-04-26), like ruby 3.4.9, Oracle GraalVM Native [arm64-darwin23] backtrace_alias.rb:3:in 'Parent#original' backtrace_alias.rb:11:in '<main>' backtrace_alias.rb:15:in 'Original#original' backtrace_alias.rb:23:in '<main>' ``` In #19117 there was some discussion about this, notably: https://bugs.ruby-lang.org/issues/19117#note-17 @byroot > My suggestion is for the owner. Simply put because it matches the path and other existing method representations. But actually the owner isn't that, what is described here is the original module of the method definition, same as the expected from this issue. https://bugs.ruby-lang.org/issues/19117#note-18 @eregon > It must be the owner, anything else would be very confusing. > I believe nobody wants String#then (there is no such method), they want to see Kernel#then. Where I was wrong about owner being the only thing. I was also expressing we should show where the method is defined, but I overlooked the "originally" part (aliases, define_method, etc). Also CC @mame who implemented the change. I think this is worth fixing for Ruby 4.1 (not sure if worth backporting). -- https://bugs.ruby-lang.org/

3 4

[ruby-core:126160] [Ruby Feature#22212] Add Thread::Backtrace::Location#source_range
by Eregon (Benoit Daloze) 06 Aug '26

06 Aug '26

Issue #22212 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #22212: Add Thread::Backtrace::Location#source_range https://bugs.ruby-lang.org/issues/22212 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- ## Motivation The main motivation is to be able to implement `Prism.find(Thread::Backtrace::Location)` precisely and cleanly on any Ruby implementation, in a way which does not depend on implementation details like `node_id`. For that we need the start/end line/column and the `absolute_path`, which is exactly what `Ruby::SourceRange` provides. In https://bugs.ruby-lang.org/issues/21998 we added `source_range` for `{Method,UnboundMethod,Proc}`. However we also need `source_range` for `Thread::Backtrace::Location` as this is used in `error_highlight`, `power_assert`, etc. Those tools currently use `RubyVM::AbstractSyntaxTree.node_id_for_backtrace_location(Thread::Backtrace::Location)`, however: * that's a CRuby-only experimental API * it exposes CRuby internals (`node_id`) * it adds a lot of complexity for all usages because they need to handle both `Prism::Node` and `RubyVM::AbstractSyntaxTree::Node`. We solve all of this by adding a new portable API which exposes universal concepts like line and column, which are stable to find AST nodes. ## Implementation How can we get the start/end line/column when we only keep the start line in CRuby? By re-parsing, and specifically by re-parsing with *exactly* the same parser that the interpreter used to compile to bytecode. That way there is no issue of using different Prism versions, it's the Prism C library built in CRuby, or `parse.y` in `--parser=parse.y` mode. Either way, we reparse to extract the start/end line/column. We make the returned start/end line/column match for both `Prism` and `parse.y`, in practice the only difference is for calls with blocks, where we adapt the location from parse.y to match Prism. One can then easily use Prism to get a node matching that `Ruby::SourceRange` and use the resulting `Prism::Node` as they wish. This also means all versions of Prism can be used, and for example if some dependency requires some specific version of Prism it works fine and is not a problem. As a result, the user of this API can choose the Prism version they want and always get a `Prism::Node` (and not having to handle `RubyVM::AbstractSyntaxTree::Node` too, or a duplicate `Ruby::Node` API as mentioned in #21795). PR: https://github.com/ruby/ruby/pull/18043 -- https://bugs.ruby-lang.org/

5 8

[ruby-core:126291] [Ruby Feature#9779] Add Module#descendants
by matz (Yukihiro Matsumoto) 06 Aug '26

06 Aug '26

Issue #9779 has been updated by matz (Yukihiro Matsumoto). Accepted. Let's define `Module#descendants`. This settles the question I left open in [#14394](https://bugs.ruby-lang.org/issues/14394#note-38). `Class#subclasses` already lets you write the transitive closure for classes in Ruby, but there is no equivalent primitive for modules, so `Module` is where this method actually adds something. Defining it there also gives `Class` the method for free. Not including `self` is fine too. It departs from `ancestors`, but it agrees with `Class#subclasses` and with ActiveSupport's `descendants`, and `[mod, *mod.descendants]` is available when needed. Once this is merged, I think [#14394](https://bugs.ruby-lang.org/issues/14394) can be closed. Matz. ---------------------------------------- Feature #9779: Add Module#descendants https://bugs.ruby-lang.org/issues/9779#change-118388 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- Now classes have links to their subclasses, so how about to add Module#descendents? ```ruby class X end class Y < X end class Z < Y end p X.descendents #=> [X, Y, Z] module A end module B include A end module C include A end p A.descendents #=> [A, C, B] ``` One of my own use cases is to implement AspectJ like pointcut which matches all subclasses of the given class. Considerations: * Should the return value of Module#descendents include self? * Should the return value of Module#descendents include singleton classes? I attach a patch, where the return value includes both self and singleton classes. ---Files-------------------------------- 0001-Add-Module-descendents.patch (3.75 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126165] [Ruby Feature#22213] Allow no-argument and chained calls of Proc#refined
by shugo (Shugo Maeda) 06 Aug '26

06 Aug '26

Issue #22213 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22213: Allow no-argument and chained calls of Proc#refined https://bugs.ruby-lang.org/issues/22213 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- ## Abstract Currently, `Proc#refined` rejects no-argument and chained calls, because I wasn't sure what the desired behavior should be. How about returning the receiver for no-argument calls: ```ruby original = -> {} refined = original.refined p refined.equal?(original) #=> true ``` and activating all the given modules for chained calls? ```ruby module M refine String do def shout = upcase + "!" end end module M2 refine Integer do def doubled = self * 2 end end original = ->(s, i) { [s.shout, i.doubled] } refined = original.refined(M).refined(M2) # the same result as original.refined(M, M2) refined.call("hi", 3) #=> ["HI!", 6] ``` ## Motivation This change is necessary to make `Proc#refined` composable. A no-argument call of `Proc#refined` is a no-op, but it's useful when the arguments are calculated at runtime: ```ruby def foo(prc, *modules) ... refined = prc.refined(*modules) ... end ``` If an empty module list were rejected, a guard like `unless modules.empty?` would be needed. A chained call of `Proc#refined` is useful to extend existing DSLs: ```ruby require "packrat_parser" require "mathn" class MathParser < PackratParser def define(sym, &block) # PackratParser#define also calls Proc#refined super(sym, &block.refined(Math::N)) end end parser = MathParser.new { ... define :multitive do [:primary, "*", :multitive].map { |x, _, y| x * y } | [:primary, "/", :multitive].map { |x, _, y| x / y } | :primary end ... } parser.parse("1 / 2") #=> (1/2) ``` ## Formal semantics With this proposal, `Proc#refined` can be formalized as a monoid action on Procs created from a block, where the acting monoid is the sequences of modules under concatenation, with the empty sequence as its unit. Writing ≃ for behavioral equivalence, the action satisfies the unit and associativity laws: ``` prc.refined ≃ prc # unit law prc.refined(*ms).refined(*ns) ≃ prc.refined(*ms, *ns) # associativity law ``` Note that the unit law holds for any Proc, since `refined` with no modules returns the receiver itself. I've written a formalization in the Rocq Prover: https://github.com/shugo/ruby-refinements-semantics It abstracts away the details irrelevant to refinements. ## Design decisions ### The receiver or a copy for no-argument calls Returning a copy was also considered, but I chose to return the receiver, following precedents such as `Data#with` and `Enumerator::Lazy#lazy`. Mutable containers tend to return a copy even for a no-op, but `Proc#refined` is closer to the former group. ### Extend or replace for chained calls If a chained call replaced the receiver's refinements instead of extending them, `prc.refined(M).refined(M2)` would activate only `M2`. That breaks the associativity law above, and makes chaining useless for the DSL case in Motivation. Extending also matches nested `using`, where refinements activated later take precedence. ## Implementation Pull request: https://github.com/ruby/ruby/pull/18052 `Proc#refined` on an already refined Proc is not memoized: the cache would be keyed on short-lived copies, and entries are retained for the VM's lifetime, so it would grow without bound. A performance warning is emitted under `Warning[:performance] = true`, and passing all the modules in a single call is more efficient. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125775] [Ruby Feature#22118] Introduce Basic Bit Operations into String
by hasumikin (hitoshi hasumi) 06 Aug '26

06 Aug '26

Issue #22118 has been reported by hasumikin (hitoshi hasumi). ---------------------------------------- Feature #22118: Introduce Basic Bit Operations into String https://bugs.ruby-lang.org/issues/22118 * Author: hasumikin (hitoshi hasumi) * Status: Open ---------------------------------------- This PR implements a subset of the specification proposed in the parent feature ticket #22082 PR URL: [placeholder to be updated] ## Methods implemented with the same specification as the parent ticket * `String#bit_at(offset, lsb_first: true) -> true | false | nil` * `String#bitwise_not -> String` * `String#bitwise_not! -> self` * `String#bitwise_and(other) -> String` * `String#bitwise_and!(other) -> self` * `String#bitwise_or(other) -> String` * `String#bitwise_or!(other) -> self` * `String#bitwise_xor(other) -> String` * `String#bitwise_xor!(other) -> self` ## Methods with range-oriented forms omitted for now The parent ticket also included range-oriented forms for some methods. In this PR, those range arguments are intentionally omitted, and the methods are limited to simpler forms. Range support can be considered as a future extension. * `String#bit_count -> Integer` * `String#bit_set(offset, lsb_first: true) -> self` * `String#bit_clear(offset, lsb_first: true) -> self` * `String#bit_flip(offset, lsb_first: true) -> self` In particular, `String#bit_count` currently takes no arguments. It does not accept a range, offset/length pair, or `lsb_first:` keyword. --- ## Remaining design questions even after narrowing the scope The overall direction of adding these methods has already been approved by Matz. The remaining questions are mostly about naming and API details. ### 1. Why the `bitwise_*` prefix is used In the parent ticket, all other methods are related to bit positions: they either take bit-position arguments, yield bit positions, or operate on a specified bit range. In contrast, the `bitwise_*` methods are whole-data operations. They apply to the entire string as a fixed-size bitmap and do not expose bit positions or bit ordering. The `bitwise_*` prefix is intended to make this distinction explicit. ### 2. Bit numbering #### `lsb_first: true` (default) Within each byte, `offset = 0` is the LSB. Numbering proceeds upward through byte[0] and then continues at the LSB of byte[1]: ```text byte[0] byte[1] offset: 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 bit: b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 ^ ^ LSB LSB offset = byte_index * 8 + bit_in_byte ``` #### `lsb_first: false` for MSB-first Byte order is preserved (`byte[0]` is still first), but within each byte numbering starts at the MSB: ```text byte[0] byte[1] offset: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 bit: b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 ^ ^ MSB MSB offset = byte_index * 8 + (7 - bit_in_byte) ``` * Whether `lsb_first:` is needed at all, or whether an equivalent mechanism should exist under another name? * If such a mechanism is needed, whether `lsb_first:` is the right keyword name? * If `lsb_first:` is acceptable, should its default be `true`? My point is that `lsb_first:` is needed because both bit numbering conventions are used in real byte-buffer formats. LSB-first is the more common convention for general in-memory bitmap use, including formats and APIs such as Apache Arrow validity bitmaps, ext4 block bitmaps, Roaring bitmaps, Linux/BSD bitmap APIs, and hardware register descriptions. MSB-first is also needed for domains such as RFC-style network protocol diagrams, PNG low-bit-depth scanlines, BitTorrent bitfields, and some compressed bit streams. The keyword only controls bit numbering within each byte. Byte order itself is unchanged. ### 3. Out-of-range behavior `String#bit_at` returns `nil` when the bit offset is out of range. On the other hand, mutating methods such as `String#bit_set`, `String#bit_clear`, and `String#bit_flip` raise `IndexError` for an out-of-range bit offset. This follows the same general distinction as read-like access versus write-like access: reading a missing position can return `nil`, but mutating a missing position should not silently do nothing. ### 4. Negative bit offsets Negative bit offsets are rejected with `IndexError`. Although Ruby often uses negative indices to count from the end, combining negative bit offsets with the `lsb_first: true/false` mechanism would make the numbering rule harder to explain and reason about. The API keeps bit offsets as non-negative flat positions from the beginning of the string. ### 5. Length mismatch for binary bitwise operations `String#bitwise_and`, `String#bitwise_or`, and `String#bitwise_xor` require both operands to have the same byte size. If the byte sizes differ, they raise `ArgumentError`. This avoids implicit truncation or zero-padding. Since these methods operate on strings as fixed-size bitmaps, requiring equal sizes makes the operation explicit and predictable. -- https://bugs.ruby-lang.org/

5 9

[ruby-core:126227] [Ruby Bug#22225] YJIT regenerates a branch while a duplicate target still points to the invalidated block
by cosgroveb (Brian Cosgrove) 05 Aug '26

05 Aug '26

Issue #22225 has been reported by cosgroveb (Brian Cosgrove). ---------------------------------------- Bug #22225: YJIT regenerates a branch while a duplicate target still points to the invalidated block https://bugs.ruby-lang.org/issues/22225 * Author: cosgroveb (Brian Cosgrove) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-03T03:11:21Z master f622e12503) +YJIT dev +PRISM [aarch64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- YJIT adds one incoming-list entry for each branch target that points to a block. When both targets point to the same block, that block's incoming list contains the same `BranchRef` twice. `invalidate_block_version` processes those entries separately. For the first entry, it redirects one target and immediately calls `regenerate_branch`. The other target still references the invalidated block. The following assertion fails immediately before that call: ```patch diff --git a/yjit/src/core.rs b/yjit/src/core.rs index d08cd1fb26..4555081ae2 100644 --- a/yjit/src/core.rs +++ b/yjit/src/core.rs @@ -4282,6 +4282,18 @@ pub fn invalidate_block_version(blockref: &BlockRef) { } } + assert!( + branch.targets.iter().all(|target| unsafe { + // SAFETY: no mutation. + target + .ref_unchecked() + .as_ref() + .and_then(|target| target.get_block()) + != Some(*blockref) + }), + "regeneration started while a branch target still referenced the invalidated block" + ); + // Rewrite the branch with the new jump target address let old_branch_size = branch.code_size(); regenerate_branch(cb, branch); ``` This Ruby script triggers the assertion: ```ruby # duplicate_target_invalidation.rb module DuplicateTargetInvalidation TARGET = 1 def self.call(condition) if condition 1 else 2 end TARGET end end 3.times do |index| DuplicateTargetInvalidation.call(index.even?) end DuplicateTargetInvalidation.send(:remove_const, :TARGET) puts "completed" ``` Save the patch as `assert-no-invalidated-target-before-regeneration.patch` and the script as `duplicate_target_invalidation.rb`. From CRuby `ruby 4.1.0dev`: ```sh git apply assert-no-invalidated-target-before-regeneration.patch ./autogen.sh mkdir build cd build ../configure --enable-yjit=dev make -j"$(nproc)" ./ruby --yjit-call-threshold=1 ../duplicate_target_invalidation.rb ``` The process aborts before printing `completed`: ```text [BUG] YJIT: panicked at yjit/src/core.rs:4285:9: regeneration started while a branch target still referenced the invalidated block ``` regenerate_branch runs with one target redirected to a stub and the other still pointing at the invalidated block. That can leave generated code jumping back into code YJIT just invalidated. -- https://bugs.ruby-lang.org/

3 8

[ruby-core:126246] [Ruby Bug#22228] Do a major GC in YJIT test helper `assert_compiles` before running the test code
by jprokop (Jarek Prokop) 04 Aug '26

04 Aug '26

Issue #22228 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #22228: Do a major GC in YJIT test helper `assert_compiles` before running the test code https://bugs.ruby-lang.org/issues/22228 * Author: jprokop (Jarek Prokop) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-04T15:30:26Z master 036159508e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I was debugging why a YJIT test added from backport to 3.3.11 with GC.stress fails downstream. This revealed an assumption in the assert_compiles, that the environment is "clean", or as default as possible. `assert_compiles` already sanitizes environment with `--disable-gems` and `reset_stats!` call. I'd like to propose the `assert_compiles` method to trigger a GC.start before executing the test proc, and before the stats reset. While the issue described below does not happen on default Rubies 3.4 and 4.0, it could enhance the YJIT test environment. I was investigating downstream test failure on Ruby 3.3.11 (and later 3.3.12) [0] that appeared after backport of: https://bugs.ruby-lang.org/issues/21266 Where the tests in YJIT expects no exits by default: Provided as a default here: https://github.com/ruby/ruby/blob/3e646aee/test/ruby/test_yjit.rb#L2015 Expected as part of condition here: https://github.com/ruby/ruby/blob/3e646aee/test/ruby/test_yjit.rb#L2080 Downstream we insert hook for optional ABRT error reporting for Ruby: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad5… Relevant patchfile: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad5… We create empty `abrt.rb` to test with later on: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad5… To reproduce the failure in 3.3, both the patch and the file are required to exist for the failure at [0] to appear. Later I found that parse.y opens a file to load the abrt.rb and registers it with Ruby GC, which causes zombie and interrupt on `GC.stress=true`, since prism parser became default, these failures no longer appear as the parser does not copy parse.y's approach of registering the opened file with Ruby GC. The note on #19921 https://bugs.ruby-lang.org/issues/19921#note-20 regarding this was correct and it's also the earliest known appearance of the issue. --- [0] Test failure result: TestYJIT#test_proc_block_with_kwrest = 0.08 s 1) Failure: TestYJIT#test_proc_block_with_kwrest [/builddir/build/BUILD/ruby-3.3.11/test/ruby/test_yjit.rb:1531]: Expected no exits, but got: {:send=>1} Reasons: method call fallback reasons: iseq_has_kwrest: 1 (100.0%) invokeblock fallback reasons: proc: 2 (100.0%) invokesuper fallback reasons: (all relevant counters are zero) method call exit reasons: interrupted: 1 (100.0%) invokeblock exit reasons: (all relevant counters are zero) invokesuper exit reasons: (all relevant counters are zero) getblockparamproxy exit reasons: (all relevant counters are zero) getinstancevariable exit reasons: (all relevant counters are zero) setinstancevariable exit reasons: (all relevant counters are zero) leave exit reasons: interp_return: 6 (100.0%) left shift (ltlt) exit reasons: (all relevant counters are zero) invalidation reasons: constant_ic_fill: 2 (100.0%) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126237] [Ruby Bug#18947] Unexpected Errno::ENAMETOOLONG on Windows
by hsbt (Hiroshi SHIBATA) 04 Aug '26

04 Aug '26

Issue #18947 has been updated by hsbt (Hiroshi SHIBATA). Two questions before this goes further. * The bit is set in `rb_w32_sysinit`, so only hosts that call `ruby_sysinit` get it, which effectively means `ruby.exe`. Embedders that do their own initialization keep the 260 character limit. Should I move it somewhere every embedder reaches? * `IsLongPathAwareProcess` is undocumented. golang has set it since 1.23, but Microsoft's Go maintainers proposed removing it. The alternative is `\\?\` prefixing at about 15 call sites, which still cannot fix `Dir.chdir` or `require`. ---------------------------------------- Bug #18947: Unexpected Errno::ENAMETOOLONG on Windows https://bugs.ruby-lang.org/issues/18947#change-118323 * Author: inversion (Yura Babak) * Status: Open * Assignee: windows * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x64-mingw-ucrt] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- On Windows 10, I am working on a script to copy a complex folder structure. Pathname and FileUtils work fine for me until there is a folder with a **very long path** (>260 chars). Normally you cannot access such a folder with Ruby. The next operations will raise `Errno::ENOENT` ``` ruby Pathname.new(300_chars_path).children FileUtils.mkpath(300_chars_path) ``` But there is a way in Windows to remove the MAX_PATH limitation. You can find a small .reg file in this article: https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-lim… After changing this system option, things start to work strangely in Ruby. This will now raise `Errno::ENAMETOOLONG`: ``` ruby Pathname.new(300_chars_path).children ``` But at the same time, you can create a folder with such a long path and write-read a file in it ``` ruby FileUtils.mkpath(300_chars_path) file = Pathname.new(300_chars_path+'/file.txt') file.write 'oooooooooo' puts Pathname.new(300_chars_path+'/file.txt').read ``` So you can work with individual items but attempts to list such folders' content fail (`.children`, `.glob`, `.copy`, etc). In my case, deep `.glob` is broken for all the parent folders of that deep long-path folder (( The only way I found for listing is ``` ruby require 'win32ole' fso = WIN32OLE.new 'Scripting.FileSystemObject' for file in fso.GetFolder(300_chars_path).files file.name file.path.length end ``` But using this workaround breaks all my code workflow built on top of Pathname and FileUtils ((. So for me, it looks like some operations with long-path folders are not working just because in Ruby there is a check for the path length and not a real operation problem. And in some places (see .mkpath) there is no such check and all works fine. Also notice that other applications on Windows have no problems with long-path folders (like Total Commander). Please consider reviewing if we really need to raise `Errno::ENAMETOOLONG` if the `LongPathsEnabled` option is enabled in the Windows registry. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115016] [Ruby master Bug#19921] TestYJIT#test_bug_19316 test failure
by vo.x (Vit Ondruch) 03 Aug '26

03 Aug '26

Issue #19921 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19921: TestYJIT#test_bug_19316 test failure https://bugs.ruby-lang.org/issues/19921 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-12 master 52709a4862) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Testing with 52709a4862 on Fedora Rawhide, I observe following failure: ~~~ 94) Failure: TestYJIT#test_bug_19316 [/builddir/build/BUILD/ruby-3.3.0-52709a4862/test/ruby/test_yjit.rb:1126]: Expected no exits, but got {:opt_and=>1} ~~~ -- https://bugs.ruby-lang.org/

6 21