I've submitted a PR that implements backwards compatibility for Set subclasses, without affecting Set itself: https://github.com/ruby/ruby/pull/15228 @Eregon can you try it with concurrent-ruby and see if it resolves your issue?jeremyevans0 (Jeremy Evans)
Eregon (Benoit Daloze) wrote in #note-13: > jeremyevans0 (Jeremy Evans) wrote in #note-11: > ... I submitted a pull request that implements what @knu suggested: https://github.com/ruby/ruby/pull/15228 It allows subclasses to use the...jeremyevans0 (Jeremy Evans)
wsfulton (William Fulton) wrote in #note-4: > Fixing this warning, in particular, removes undefined behaviour. Can you explain what the undefined behavior is? My understanding is that in both C and C++, the behavior is defined to ze...jeremyevans0 (Jeremy Evans)
wsfulton (William Fulton) wrote in #note-2: > This happens when compiling an EXTENSION. We have always used -Wmissing-field-initializers in our extensions and now they are broken. New Ruby releases really MUST NOT introduce new warnings...jeremyevans0 (Jeremy Evans)
tenderlovemaking (Aaron Patterson) wrote in #note-10: > mame (Yusuke Endoh) wrote in #note-9: > ... I agree with @mame and @tenderlovemaking. Removing special handling of infinite ranges avoids the original issue (calling `size`), as ...jeremyevans0 (Jeremy Evans)
Dan0042 (Daniel DeLorme) wrote in #note-24: > So the issue here is that pathname doesn't use this `rb_provide` ? pathname does use `rb_provide`: ``` $ git grep rb_provide pathname.c pathname.c: rb_provide("pathname.so"); ```...jeremyevans0 (Jeremy Evans)
Dan0042 (Daniel DeLorme) wrote in #note-21: > But that doesn't happen with `require "set"`. In fact, the "set" gem appear to never be loaded at all?! Sorry, I can't make sense of these divergent behaviors. It's normal behavior when m...jeremyevans0 (Jeremy Evans)
Dan0042 (Daniel DeLorme) wrote in #note-19: > Doesn't `Set` have the same problems? No. > ... In Ruby 3.2, `set` was default gem, and `Set` was an autoloaded constant. The `set` library was not required when a method was called (u...jeremyevans0 (Jeremy Evans)
I found that you don't even need to change the visibility twice. This issue affects all refinement visibility change methods where the method whose visibility is changed by the refinement is in an ancestor of the refined class. Here's a ...jeremyevans0 (Jeremy Evans)
Probably hitting this issue: https://github.com/brianmario/mysql2/pull/1410 . As @luke-gru mentioned, using mysql 0.5.6 should work around the issue until mysql2 releases a fixed gem.jeremyevans0 (Jeremy Evans)
jeremyevans0 (Jeremy Evans)03:24 AM Ruby Bug #21375: Set[] does not call #initialize