Add support for Ruby 3.2 attached_object#7636
Closed
edipofederle wants to merge 92 commits intojruby:ruby-3.2from
Closed
Add support for Ruby 3.2 attached_object#7636edipofederle wants to merge 92 commits intojruby:ruby-3.2from
edipofederle wants to merge 92 commits intojruby:ruby-3.2from
Conversation
e509f52 to
1e327dd
Compare
Member
|
Can you rebase this to the 3.2 branch? |
Contributor
Author
Sure |
The following test will pass. * test_zip in test/mri/ruby/test_enum.rb
When the incoming UnboundMethod is from a Module not already included in the target receiver's class hierarchy, the newly bound Method should treat that method as living in a virtual module included below the receiver's class. This allows the rebound method to use `super` to call a method of the same name in the receiver's hierarchy. For the original change in CRuby (2.2) see: ruby/ruby@46f578d For the additional change to avoid the extra include class when the owner module is already in the target hierarchy, see: ruby/ruby@160b67d Fixes jruby#7548.
Additional change for bind_call to allow supering out of rebound methods. See jruby#7555. Fixes jruby#7548 for 9.4.
UnboundMethod#bind and #bind_call should bind to a virtual include class below the receiver class when the method is from a module that does not exist in the receiver's hierarchy. This allows the rebound method to call `super` to delegate to the receiver's class and ancestors. This behavioral change was introduced when `bind_call` was added but I have not found any tests, specs or documentation about the behavior change. See jruby#7548 and sorbet/sorbet#1188.
zsuper within closure was not detecting keywords from the surrounding method. This was pretty simple. We were asking current scope (closure) if it received keywords. We should be asking method scope for this.
This also adds in handling for n = 0 always returning 0 regardless of the size of m (for n << m and n >> m). Fixes jruby#7554
alias and synchronized methods are only wrappers so they should mark their source methods as being ruby2_keywords. This also put setRuby2Keywords onto DynamicMethod to make it more clear this is a Ruby thing and not an IR-specific thing (IRMethodArgs as a cast is confusing).
This change is porting from mri(numeric.c and rational.c). The following tests will pass. * test_floor_ceil_ndigits in test/mri/ruby/test_numeric.rb * test_float_round_ndigits in test/mri/ruby/test_numeric.rb
This fixes float_cmp function to return correct value when float argument is infinity. The following tests will pass. * spec/ruby/core/float/gt_spec.rb * spec/ruby/core/float/gte_spec.rb * spec/ruby/core/float/lt_spec.rb * spec/ruby/core/float/lte_spec.rb
The following test will pass. * test_remainder_infinity in test/mri/ruby/test_numeric.rb
Its absence causes an intermittent failure, likely caused by load ordering
randomness.
TestEnumerable#test_sum:
NameError: uninitialized constant TestEnumerable::SimpleDelegator
org/jruby/RubyModule.java:3947:in `const_missing'
/tmp/autopkgtest-lxc.wadx2atf/downtmp/autopkgtest_tmp/test/mri/ruby/test_enum.rb:1051:in `test_sum'
This was very narrow in scope. If you only passed in a single argument we "unwrap" it from the original ```[arg]``` and just pass arg. This in turn *spreads* whatever is there (if an array). In this case arg is the keywords arg. So the fix was to not unwrap in this case.
CRuby first attempts to call `bytes` on the given random object in order to allow random number implementations to override only that one method in order to change the random number source. We were skipping this logic and going straight back to our internal PRNG logic. This had two effects: * SecureRandom and similar classes would not always be the source for random numbers they appear to generate, since this callback to `bytes` was not happening for long-ranged random numbers. * The test_ulong_limited_no_rand test from CRuby's test_rand.rb failed 50% of the time because we continued to generate actual random numbers (1..2) rather than using the non-random overridden `bytes` method.
Not all IR instructions do the same amount of work in bytecode, so the actual bytecode size resulting from similarly-sized (in IR) methods will vary, but this does allow a key lexer method from the parser gem to compile (at 2998 IR instructions), and the resulting bytecode also appears to native JIT. We could probably go higher, but we would want to make sure that larger methods still can native JIT before blindly increasing the threshold. Relates to jruby#7589 and work to get the parser gem to fully JIT.
Fixes jruby#7570 Fixes jruby#6365 See jruby#7600 for the same PR against 9.3, which needs work because the tests do not pass with newer Psych's safe_load logic.
Relates to jruby#7630, which may be a new incompatibility in rspec.
1e327dd to
8488b6c
Compare
Contributor
Author
|
Closing in favor of #7638 (I messed up with the rebase :D) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Feature: https://bugs.ruby-lang.org/issues/12084
Reference: #7517