Issue #19746 has been reported by nobu (Nobuyoshi Nakada).
----------------------------------------
Bug #19746: `String#index` with regexp and too large offset doesn't clear `$~`
https://bugs.ruby-lang.org/issues/19746
* Author: nobu (Nobuyoshi Nakada)
* Status: Open
* Priority: Normal
* Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED
----------------------------------------
```ruby
/./ =~ "a"
p "x".index(/0/, 4) #=> nil
p $~ #=> #<MatchData "a">
```
while `rindex` does.
```ruby
/./ =~ "a"
p "x".rindex(/0/, 4) #=> nil
p $~ #=> nil
```
It seems since 1.9.
--
https://bugs.ruby-lang.org/
Issue #19535 has been reported by byroot (Jean Boussier).
----------------------------------------
Misc #19535: Instance variables order is unpredictable on objects with `OBJ_TOO_COMPLEX_SHAPE_ID`
https://bugs.ruby-lang.org/issues/19535
* Author: byroot (Jean Boussier)
* Status: Open
* Priority: Normal
----------------------------------------
### Context
I've been helping the Mastodon folks in investigating a weird Marshal deserialization bug they randomly experience since they upgraded to Ruby 3.2: https://github.com/mastodon/mastodon/issues/23644
Ultimately the bug comes from a circular dependency issues in the object graph that is serialized when one call `Marshal.dump` on an `ActiveRecord::Base` object.
A simplified reproduction to better explain the problem is:
```ruby
class Status
def normal_order
@attributes = { id: 42 }
@relations = { self => 1 }
self
end
def inverse_order
@relations = nil
@attributes = { id: 42 }
@relations = { self => 1 }
self
end
def hash
@attributes.fetch(:id)
end
end
s = Marshal.load(Marshal.dump(Status.new.normal_order))
s = Marshal.load(Marshal.dump(Status.new.inverse_order))
```
In short, that `Status` object is both the top level object, and is referenced as a key in a hash, in that same payload. It also defined a custom `#hash` method, that requires some other attribute to be set.
It all "works" as long as `@attributes` is dumped before `@relations`.
### Problem
The above micro-reproduction uses two different shapes to demonstrate the ordering issues, but in both case the ordering is predictable.
However if you generate too many shapes from a single class, it will be marked as `TOO_COMPLEX` and future instance will have their instance variables backed by an `id_table`, which is unordered, and will cause a similar issue.
I definitely consider this a bug on the Rails side, and I will do what I can so that Rails doesn't depend on that implicit ordering.
However it's unlikely we'll be able to fix older version, and other users may run into this issue when upgrading to Ruby 3.2, so I think it may be worth to try to preserve some sort of predicable ordering, at least for a few more versions.
Additionally, debugging it was made particularly difficult, because it would work fine initially, and then break after enough shapes had been generated. Generally speaking I think such semi-predictable behavior is much worse than a fully random behavior (similar to how Go randomize keys order in their maps).
### Historical behavior
On Ruby 3.1 and older, the instance variables ordering was defined by the order in which each ivar appeared for the very first time:
```ruby
class Foo
def set
@a = 1
@b = 2
@c = 3
self
end
def inverse_order
@c = 3
@b = 2
@a = 1
self
end
end
p Foo.new.set.instance_variables # => [:@a, :@b, :@c]
p Foo.new.inverse_order.instance_variables # => [:@a, :@b, :@c]
```
This means that the order could be different from once execution of the program to another, but would remain stable inside a single process.
On 3.2, it's now defined by the order in which each ivar appeared in that specific object instance:
```ruby
[:@a, :@b, :@c]
[:@c, :@b, :@a]
```
Except, if the object is backed by an `id_table`, in which case it's fully unpredictable.
### Possible changes
I discussed this with @tenderlovemaking, and he suggested we could change the `id_table` for an `st_table` so that the ordering could be predictable again, and would behave like objects with a non-complex shape.
Another possibility would be to preserve the observable behavior of 3.1 and older.
Or of course we could clearly specify that the ordering is random, but if so I think it would be wise to make it always random so that this class of bugs has a much higher chance to be caught early in testing rather than in production.
cc @Eregon as I presume this has implications on TruffleRuby as well.
--
https://bugs.ruby-lang.org/
Issue #19640 has been reported by ioquatix (Samuel Williams).
----------------------------------------
Bug #19640: `IO#puts` can generate zero length iov which can cause rb_bug crash.
https://bugs.ruby-lang.org/issues/19640
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED
----------------------------------------
In the fiber scheduler, `IO#puts ""` or `IO#puts nil` can generate a zero length `iov` which causes `io_binwritev_internal` to fail since the result is zero.
We need to fix `IO#puts` so that it does not generate zero length writes, but also we fix `io_binwritev_internal` to handle this case more robustly.
Fix: https://github.com/ruby/ruby/pull/7806/files
--
https://bugs.ruby-lang.org/
Issue #19625 has been reported by k0kubun (Takashi Kokubun).
----------------------------------------
Bug #19625: Ruby 3.2 MJIT never triggers JIT compaction
https://bugs.ruby-lang.org/issues/19625
* Author: k0kubun (Takashi Kokubun)
* Status: Closed
* Priority: Normal
* Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED
----------------------------------------
[This patch](https://github.com/ruby/ruby/pull/6900) accidentally removed a condition to trigger JIT compaction from Ruby 3.2.
This PR https://github.com/ruby/ruby/pull/7777 makes it work again. This ticket is to request a backport for Ruby 3.2.
--
https://bugs.ruby-lang.org/
Issue #19531 has been reported by byroot (Jean Boussier).
----------------------------------------
Bug #19531: ObjectSpace::WeakMap: replaced values still clear the key they were assigned to
https://bugs.ruby-lang.org/issues/19531
* Author: byroot (Jean Boussier)
* Status: Open
* Priority: Normal
* Backport: 2.7: WONTFIX, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED
----------------------------------------
### Reproduction script
```ruby
wmap = ObjectSpace::WeakMap.new
a = "A"
b = "B"
wmap[1] = a
wmap[1] = b # the table entry with 1 is still in the list of entries to clear when `a` is GCed
a = nil
GC.start
p wmap[1] # Should be `"B"`, but is `nil`
```
### Explanation
What happens is that when we set `wmap[1] = "A"`, WeakMap internally keeps a list of keys to clear when `"A"` is GCed, e.g. pseudo code:
```ruby
class WeakMap
def []=(key, value)
@hash[key] = value
@reverse[value] << key
end
end
```
But it doesn't clear previously kept mapping when a key is overwritten.
I'll work on a fix.
### References
https://github.com/protocolbuffers/protobuf/pull/12216
--
https://bugs.ruby-lang.org/
Issue #19351 has been reported by hsbt (Hiroshi SHIBATA).
----------------------------------------
Bug #19351: Promote bundled gems at Ruby 3.3
https://bugs.ruby-lang.org/issues/19351
* Author: hsbt (Hiroshi SHIBATA)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
In Ruby 3.2, the default gems and bundled gems are changed only adding `syntax_suggest`. I and some committers are considering promote default gems to bundled gems again for Ruby 3.3+.
We hope to keep the current developer experience with dependency resolution and ignore the additional work like "Put gem "xxx" into your Gemfile" for developers.
### Proposal
We propose the following libraries will promote default gems to bundled gems at Ruby 3.3. They are not the dependencies of Rails and RubyGems/Bundler.
```
abbrev
getoptlong
optparse
observable
resolv
resolv-replace
rinda
un
fcntl
nkf
syslog
win32ole
```
### Additional works
I also propose to poromote rails dependencies:
```
ostruct
base64
irb
rdoc
tsort
singleton
delegate
```
and gems maintained by @kou
```
csv
strscan
fiddle
stringio
```
But if we promote them to bundled gems, many of users need to add `gem "csv"` into their Gemfile. I'm considering to avoid this situation.
Can we the specific feature of bundled gems to RubyGems or Bundler? Example, bundler have allowed list for bundled gems. So, listed gems could be require without Gemfile under the bundle exec.
--
https://bugs.ruby-lang.org/
Issue #19679 has been reported by jemmai (Jemma Issroff).
----------------------------------------
Misc #19679: Migrate Wiki from bugs.ruby-lang.org to ruby/ruby GitHub repository
https://bugs.ruby-lang.org/issues/19679
* Author: jemmai (Jemma Issroff)
* Status: Open
* Priority: Normal
----------------------------------------
# Background
There is currently a Wiki at https://bugs.ruby-lang.org/projects/ruby/wiki which contains documentation of processes, documentation of code, developers' meeting notes, and various other notes.
There are three main problems with the current Wiki setup:
* **Out of date:** Much of the documentation is out of date, or no longer relevant (for example: [How to Release Ruby 1.9](https://bugs.ruby-lang.org/projects/ruby/wiki/HowToReleaseRuby19))
* **Duplication:** Some of this documentation exists both in the Wiki and in the docs in ruby/ruby (for example: [DTrace Probes in the docs](https://docs.ruby-lang.org/en/master/dtrace_probes_rdoc.html) and [DTrace Probes in the Wiki](https://bugs.ruby-lang.org/projects/ruby/wiki/DTraceProbes)
* **Editing docs is limited:** Only Core contributors can edit the Wiki, and version control is more limited (for example: I couldn't edit any mistakes I found in the Wiki while preparing this issue).
# Proposal
This proposal is to migrate any still relevant docs within the Wiki from the bugs.ruby-lang.org Wiki to a new GitHub Wiki. I have categorized all of the Wiki pages in [this google sheet](https://docs.google.com/spreadsheets/d/1Ld83ZKxknYgECXxNSh28fjFw82pS… and given my analysis of which should be migrated. If there are any pages that should be migrated which aren't currently included, please indicate so in the comments and we will migrate them.
I also propose we migrate the old Developers' Meeting notes to the [developer's meeting repository](https://github.com/ruby/dev-meeting-log).
I spoke about this idea with @hsbt at Ruby Kaigi, and he and @naruse suggested that I write this proposal.
# Implementation
0. Before I begin the migration, someone who has the appropriate permissions on GitHub will need [to create the Wiki](https://docs.github.com/en/communities/documenting-your-project-with-…
1. I will migrate all pages listed in the Google sheet with "migrate?" checked to the new GitHub wiki
2. I will migrate all of the Developers' Meeting Notes to the developers' meeting repo
3. Someone who has the appropriate permissions will need to remove the Wiki from bugs.ruby-lang.org
4. I will update all GitHub wiki pages with "update?" checked in the Google Sheet to reflect the latest state
--
https://bugs.ruby-lang.org/