ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "jeremyevans0 (Jeremy Evans) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "jeremyevans0 (Jeremy Evans)" <noreply@ruby-lang.org>
Subject: [ruby-core:123131] [Ruby Bug#21538] initialize_dup not called when duping class/module
Date: Sat, 30 Aug 2025 00:16:36 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-114458.20250830001636.10442@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-21538.20250811132623.10442@ruby-lang.org

Issue #21538 has been updated by jeremyevans0 (Jeremy Evans).


The example given isn't a bug. `initialize_dup` is called on the new instance (in this example, the instance of `Class`), and `dup` does not copy singleton classes. If you define `Class#inititialize_dup`, it works as expected:

```ruby
class A
  def initialize_dup(_)
    puts "dup instance"
    super
  end
end
class Class
  def initialize_dup(_)
    puts "dup class"
    super
  end
end

A.new.dup
# prints "dup instance"

A.dup
# prints "dup class"
```

`dup` is different than `clone`, because `clone` copies the singleton class, and therefore will pick up singleton methods:

```ruby
class A
  def initialize_clone(_)
    puts "clone instance"
    super
  end
  def self.initialize_clone(_)
    puts "clone class"
    super
  end
end

A.new.clone
# prints "clone instance"

A.clone
# prints "clone class"
```

That being said, there are two definite bugs and another probable bug in `Class#dup`, as evidenced by this example: 

```ruby
class Class
  def initialize_dup(_)
    p ancestors
    p singleton_class.ancestors
    super
  end
end

class B
  def self.initialize_dup(_)
    puts "dup class"
    super
  end
end

class A < B
end

puts
p A.ancestors
p A.singleton_class.ancestors

puts
C = A.dup

puts
p C.ancestors
p C.singleton_class.ancestors
```

Output on Ruby 3.4 (with comments on bugs):

```
[A, B, Object, Kernel, BasicObject]
[#<Class:A>, #<Class:B>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

# Probable Bug: During initialize_dup, ancestors are missing,
# and therefore ancestor initialize_dup singleton method not called
[#<Class:0x00000d7e572e8ca8>]
[#<Class:#<Class:0x00000d7e572e8ca8>>, Class, Module, Object, Kernel, BasicObject]

# Definite Bug 1: after dup, singleton class ancestors are missing
[C, B, Object, Kernel, BasicObject]
[#<Class:C>, Class, Module, Object, Kernel, BasicObject]
```

Output on master branch:

```
[A, B, Object, Kernel, BasicObject]
[#<Class:A>, #<Class:B>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

# Definite Bug 2: calling singleton_class inside Class#initialize_dup
# results in TypeError
[#<Class:0x00000b7eeb88aca0>]
[#<Class:#<Class:0x00000b7eeb88aca0>>, Class, Module, Object, Kernel, BasicObject]
-:5:in 'Module#initialize_copy': already initialized class (TypeError)
        from -:5:in 'Kernel#initialize_dup'
        from -:5:in 'Class#initialize_dup'
        from -:25:in 'Kernel#dup'
        from -:25:in '<main>'
```

The reason I call the first bug probable and not definite is that it is at least defensible that ancestor setup occurs inside `dup`, but after the call to `Class#initialize_dup`. I still think it should be considered a bug and fixed. I'm guessing fixing definite bug 2 requires fixing the probable bug.

For `clone`, there is a similar issue of missing ancestors (but not singleton class ancestors) inside `initialize_clone`:

```ruby
class B
  def self.initialize_clone(_)
    p ancestors
    p singleton_class.ancestors
    puts "clone class"
    super
  end
end

class A < B
end


puts
p A.ancestors
p A.singleton_class.ancestors

puts
C = A.clone

puts
p C.ancestors
p C.singleton_class.ancestors
```

Output:

```
[A, B, Object, Kernel, BasicObject]
[#<Class:A>, #<Class:B>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

# Probable bug: During initialize_clone, ancestors are missing
[#<Class:0x00000a047fffaab8>]
[#<Class:#<Class:0x00000a047fffaab8>>, #<Class:B>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]
clone class

[C, B, Object, Kernel, BasicObject]
[#<Class:C>, #<Class:B>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

```

----------------------------------------
Bug #21538: initialize_dup not called when duping class/module
https://bugs.ruby-lang.org/issues/21538#change-114458

* Author: chucke (Tiago Cardoso)
* Status: Open
* ruby -v: 3.4.5
* Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN
----------------------------------------
Not sure whether this is expected behaviour or not, but just leaving it here to start the debate on whether callbacks like `initialize_dup` are supposed to be called when a module or class is duped (the same happens with `initialize_copy` and `initialize_clone` btw):

    class A
      def initialize_dup(_)
        puts "dup instance"
        super
      end
      def self.initialize_dup(_)
        puts "dup class"
        super
      end
    end

    A.new.dup #=> "dup instance"
    A.dup #=> nothing



-- 
https://bugs.ruby-lang.org/
______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/

  reply	other threads:[~2025-08-30  0:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-11 13:26 [ruby-core:122945] [Ruby Bug#21538] initialize_dup not called when duping class/module chucke (Tiago Cardoso) via ruby-core
2025-08-30  0:16 ` jeremyevans0 (Jeremy Evans) via ruby-core [this message]
2025-08-30  2:13 ` [ruby-core:123133] " jeremyevans0 (Jeremy Evans) via ruby-core

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-114458.20250830001636.10442@ruby-lang.org \
    --to=ruby-core@ml.ruby-lang.org \
    --cc=noreply@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).