This adds a fastpath in class_call_alloc_func to simply return if the
class matches the one expected.
I think we could probably just remove this check, or move it to the debug
build.
[Bug #21710]
- struct.c: `struct_alloc`
It is possible for a `NEWOBJ` tracepoint call back to write fields
into a newly allocated object before `struct_alloc` had the time
to set the `RSTRUCT_GEN_FIELDS` flags and such.
Hence we can't blindly initialize the `fields_obj` reference to `0`
we first need to check no fields were added yet.
- object.c: `rb_class_allocate_instance`
Similarly, if a `NEWOBJ` tracepoint tries to set fields on the object,
the `shape_id` must already be set, as it's required on T_OBJECT to
know where to write fields.
`NEWOBJ_OF` had to be refactored to accept a `shape_id`.
[Bug #21718]
Otherwise objects that don't define it, but define a fairly liberal
`method_missing` method will run into errors that are hard to understand:
```ruby
class Foo
def method_missing(name, ...)
name
end
end
p Foo.new.inspect
```
```
'Kernel#inspect': wrong argument type Symbol (expected Array) (TypeError)
from ../test.rb:7:in '<main>'
```
Previously, you could override the class initialize_dup/initialize_clone
method and the class hierarchy would not be set correctly inside the
method before calling super.
This removes Module#initialize_copy, and instead makes Object#dup/clone
call the underlying C function (rb_mod_init_copy) before calling the
appropriate initialize_dup/initialize_clone method.
This results in the following fixes:
* The appropriate initialize_dup method is called (dup on a class
will respect superclass initialize_dup).
* Inside class initialize_dup/initialize_clone/initialize_copy,
class ancestor hierarchy is correct.
* Calling singleton_class inside initialize_dup no longer raises
a TypeError later in dup.
* Calling singleton_class.ancestors inside initialize_dup no
longer results in missing ancestors.
Fixes [Bug #21538]
Since `BUILTIN_TYPE` and `RCLASS_SINGLETON_P` are both stored in
`RBasic.flags`, we can combine these two checks in a single bitmask.
This rely on `T_ICLASS` and `T_CLASS` not overlapping, and assume
`klass` is always either of these types.
Just combining the masks brings a small but consistent 1.08x speedup on the simple case benchmark.
```
compare-ruby: ruby 3.5.0dev (2025-08-30T01:45:42Z obj-class 01a57bd6cd) +YJIT +PRISM [arm64-darwin24]
built-ruby: ruby 3.5.0dev (2025-08-30T09:56:24Z obj-class 2685f8dbb4) +YJIT +PRISM [arm64-darwin24]
| |compare-ruby|built-ruby|
|:----------|-----------:|---------:|
|obj | 444.410| 478.895|
| | -| 1.08x|
|extended | 135.139| 140.206|
| | -| 1.04x|
|singleton | 165.155| 155.832|
| | 1.06x| -|
|immediate | 380.103| 432.090|
| | -| 1.14x|
```
But with the RB_UNLIKELY compiler hint, it's much more significant, however
the singleton and enxtended cases are slowed down.
However we can assume the simple case is way more common than the other two.
```
compare-ruby: ruby 3.5.0dev (2025-08-30T01:45:42Z obj-class 01a57bd6cd) +YJIT +PRISM [arm64-darwin24]
built-ruby: ruby 3.5.0dev (2025-08-30T09:51:01Z obj-class 12d01a1b02) +YJIT +PRISM [arm64-darwin24]
| |compare-ruby|built-ruby|
|:----------|-----------:|---------:|
|obj | 444.951| 556.191|
| | -| 1.25x|
|extended | 136.836| 113.871|
| | 1.20x| -|
|singleton | 166.335| 167.747|
| | -| 1.01x|
|immediate | 379.642| 509.515|
| | -| 1.34x|
```
Now that the shape_id has been unified across all types
this helper function doesn't do much over `RBASIC_SET_SHAPE_ID`.
It still check if the write is needed, but it doesn't seem useful
in places where it's used.
The `FL_FREEZE` flag is redundant with `SHAPE_ID_FL_FROZEN`, so
ideally it should be eliminated in favor of the later.
Doing so would eliminate the risk of desync between the two, but
also solve the problem of the frozen status being global in namespace
context (See Bug #21330).
The type isn't opaque because Ruby isn't often compiled with LTO,
so for optimization purpose it's better to allow as much inlining
as possible.
However ideally only `shape.c` and `shape.h` should deal with
the actual struct, and everything else should just deal with opaque
`shape_id_t`.
Make Kernel#inspect ask which instance variables should be dumped by
the result of `#instance_variables_to_inspect`.
Co-Authored-By: Jean Boussier <byroot@ruby-lang.org>
Instead `shape_id_t` higher bits contain flags, and the first one
tells whether the shape is frozen.
This has multiple benefits:
- Can check if a shape is frozen with a single bit check instead of
dereferencing a pointer.
- Guarantees it is always possible to transition to frozen.
- This allow reclaiming `FL_FREEZE` (not done yet).
The downside is you have to be careful to preserve these flags
when transitioning.
Previously we used a flag to set whether a module was uninitialized.
When checked whether a class was initialized, we first had to check that
it had a non-zero superclass, as well as that it wasn't BasicObject.
With the advent of namespaces, RCLASS_SUPER is now an expensive
operation, and though we could just check for the prime superclass, we
might as well take this opportunity to use a flag so that we can perform
the initialized check with as few instructions as possible.
It's possible in the future that we could prevent uninitialized classes
from being available to the user, but currently there are a few ways to
do that.
This makes `RBobject` `4B` larger on 32 bit systems
but simplifies the implementation a lot.
[Feature #21353]
Co-authored-by: Jean Boussier <byroot@ruby-lang.org>
