Skip to content

[pull] master from ruby:master#921

Merged
pull[bot] merged 4 commits intoturkdevops:masterfrom
ruby:master
Apr 10, 2026
Merged

[pull] master from ruby:master#921
pull[bot] merged 4 commits intoturkdevops:masterfrom
ruby:master

Conversation

@pull
Copy link
Copy Markdown

@pull pull bot commented Apr 10, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

jhawthorn and others added 4 commits April 9, 2026 13:55
This caused out of bounds writes because of converting to a st_table.

Co-authored-by: Luke Gruber <luke.gru@gmail.com>
Co-authored-by: Matt Valentine-House <matt@eightbitraptor.com>
Co-authored-by: Luke Gruber <luke.gru@gmail.com>
Co-authored-by: Matt Valentine-House <matt@eightbitraptor.com>
Every class boots with a metaclass, and all metaclasses are subclasses
of Class, so `types::Class` has no business in `ExactBitsAndClass`.
In fact, we should never see an object whose RBasic::class is exactly
rb_cClass because classes get a metaclass on boot. So there is no
ClassExact type.

This fixes the side exits on getivar-module.rb that were introduced in
a8f3c34 ("ZJIT: Add missing guard
on ivar access on T_{DATA,CLASS,MODULE}"). The `GuardType v, Class` checked
for exactly rb_cClass and never passed.
Although the issue only occurred on debug builds, we should always be
requesting a size large enough to fit the object when it expands to the
heap, rather than just hoping the GC provides enough room.
@pull pull bot locked and limited conversation to collaborators Apr 10, 2026
@pull pull bot added the ⤵️ pull label Apr 10, 2026
@pull pull bot merged commit 4c2ae6e into turkdevops:master Apr 10, 2026
1 of 3 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants