summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-12-09Ensure super(**kw, &block) calls kw.to_hash before block.to_procJeremy Evans
Similar as previous commit, but handles the super case with explicit arguments.
2023-12-09Ensure f(**kw, &block) calls kw.to_hash before block.to_procJeremy Evans
Previously, block.to_proc was called first, by vm_caller_setup_arg_block. kw.to_hash was called later inside CALLER_SETUP_ARG or setup_parameters_complex. This adds a splatkw instruction that is inserted before sends with ARGS_BLOCKARG and KW_SPLAT and without KW_SPLAT_MUT. This is not needed in the KW_SPLAT_MUT case, because then you know the value is a hash, and you don't need to call to_hash on it. The splatkw instruction checks whether the second to top block is a hash, and if not, replaces it with the value of calling to_hash on it (using rb_to_hash_type). As it is always before a send with ARGS_BLOCKARG and KW_SPLAT, second to top is the keyword splat, and top is the passed block.
2023-12-09Add a fudge factor to the GC compaction move up/down testsKJ Tsanaktsidis
There seems to be another manifestation of bug #20021, where some of the compaction tests are failing on i686 for unrelated PR's because of fake "live" references to moved objects on the machine stack. We _could_ solve this by counting how many objects are pinned during compaction, but doing that involves pushing down the mark & pin bitset merge into gc_compact_plane and out of gc_compact_page, which I thought was pretty ugly. Now that we've solved bug #20022 though, we're able to compact arbitrarily many objects with GC.verify_compaction_references, so the number of objects we're moving is now 50,000 instead of 500. Since that's now much larger than the number of objects likely to be pinned, I think it's safe enough to just add a fudge-factor to the tests. Any _other_ change in GC.verify_compaction_references that breaks compaction is now highly likely to break the assertion by more than 10 objects, since it's operating on so many more in the first place. [Bug #20021]
2023-12-09Fix test of GVL instrumentation on Ractor sleepingJohn Hawthorn
It seems that the Ractor sleep GVL event arrives very slightly after the value becomes available and other threads wake (which makes sense) so we need a little additional time to ensure we end up in a consisteny state.
2023-12-09Add missing GVL hooks for M:N threads and ractorsJohn Hawthorn
2023-12-09Update default gems list at edb8fc24d4a51e58f283a6e7fd1b18 [ci skip]git
2023-12-09[ruby/error_highlight] Bump versionYusuke Endoh
https://github.com/ruby/error_highlight/commit/942a723d32
2023-12-09[DOC] Small fixes for documentation renderingVictor Shepelev
Mostly just fixing RDoc's incorrect treatment of `+`
2023-12-08[PRISM] Fix `PM_CALL_NODE` assignmenteileencodes
This PR fixes ruby/prism#1963. Array and variable assignment was broken for call nodes. The change checks if the `method_id` is related to assignment and if is adds a `putnil`, `setn` and a `pop`. The incorrect instructions meant that in some cases (demonstrated in tests) the wrong value would be returned. I verified that this fixes the test mentioned in the issue (run: `RUBY_ISEQ_DUMP_DEBUG=prism make test/-ext-/st/test_numhash.rb`) Incorrect instructions: ``` "********* Ruby *************" == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(4,10)> 0000 putnil ( 4)[Li] 0001 putself 0002 send <calldata!mid:tbl, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0005 putself 0006 send <calldata!mid:i, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0009 putself 0010 send <calldata!mid:j, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0013 setn 3 0015 send <calldata!mid:[]=, argc:2, ARGS_SIMPLE>, nil 0018 pop 0019 leave "********* PRISM *************" == disasm: #<ISeq:<compiled>@<compiled>:3 (3,0)-(3,10)> 0000 putself ( 3)[Li] 0001 send <calldata!mid:tbl, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0004 putself 0005 send <calldata!mid:i, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0008 putself 0009 send <calldata!mid:j, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0012 send <calldata!mid:[]=, argc:2, ARGS_SIMPLE>, nil 0015 leave ``` Fixed instructions: ``` "********* Ruby *************" == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(4,10)> 0000 putnil ( 4)[Li] 0001 putself 0002 send <calldata!mid:tbl, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0005 putself 0006 send <calldata!mid:i, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0009 putself 0010 send <calldata!mid:j, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0013 setn 3 0015 send <calldata!mid:[]=, argc:2, ARGS_SIMPLE>, nil 0018 pop 0019 leave "********* PRISM *************" == disasm: #<ISeq:<compiled>@<compiled>:3 (3,0)-(3,10)> 0000 putnil ( 3)[Li] 0001 putself 0002 send <calldata!mid:tbl, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0005 putself 0006 send <calldata!mid:i, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0009 putself 0010 send <calldata!mid:j, argc:0, FCALL|VCALL|ARGS_SIMPLE>, nil 0013 setn 3 0015 send <calldata!mid:[]=, argc:2, ARGS_SIMPLE>, nil 0018 pop 0019 leave ``` Fixes ruby/prism#1963
2023-12-08RDoc for ComplexBurdetteLamar
2023-12-08[ruby/prism] Add necessary encoding flags for symbols and regexKevin Newton
This doesn't actually fix the encodings for symbols and regex, unfortunately. But I wanted to get this change in because it is the last AST change we're going to make before 3.3 is released. So, if consumers want, they can start to check these flags to determine the encoding, even though it will be wrong. Then once we actually set them correctly, everything should work. https://github.com/ruby/prism/commit/9b35f7e891
2023-12-08[rubygems/rubygems] Upstream RubyGems changes from TruffleRubyBenoit Daloze
https://github.com/rubygems/rubygems/commit/749a508968
2023-12-08Update default gems list at f2c13ff9e8646ea1f05498707c8e97 [ci skip]git
2023-12-08[ruby/syntax_suggest] v2.0.0Schneems
https://github.com/ruby/syntax_suggest/commit/53b2a1b03c
2023-12-08[ruby/prism] A couple of small dot enhancementsKevin Newton
https://github.com/ruby/prism/commit/5642a57f39
2023-12-08[ruby/prism] Hashes need to deoptimize based on their contentsAaron Patterson
If a hash has children that are not "basic" types of objects, then we can't consider the hash to be a static literal. Fixes: #2015 https://github.com/ruby/prism/commit/ca2523137d
2023-12-08[ruby/prism] More closely match CRuby error messagesKevin Newton
https://github.com/ruby/prism/commit/1ed07a0c6d
2023-12-08Improve Fiber#kill docs and simplify the NEWS entry to let the documentation ↵Benoit Daloze
explain
2023-12-08Update default gems list at 49cdf063d6275151075ffd94c3d013 [ci skip]git
2023-12-08[ruby/set] Bump version to 1.0.4Akinori MUSHA
https://github.com/ruby/set/commit/efc8c8c9f5
2023-12-08Revert "Skip to warn like 'bigdecimal/util' feature."Hiroshi SHIBATA
This reverts commit 8f6cf72e661e36410848c1451335fd28a32cecdf.
2023-12-08Pick commit from https://github.com/rubygems/rubygems/pull/7085Hiroshi SHIBATA
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
2023-12-08Pick commit from https://github.com/rubygems/rubygems/pull/7227Hiroshi SHIBATA
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
2023-12-08[rubygems/rubygems] Migrate documentation to be generated with nronnDavid Rodríguez
https://github.com/rubygems/rubygems/commit/55281f0eaa
2023-12-08[rubygems/rubygems] Add extra blank line to `bundle outdated` docsDavid Rodríguez
If it's not there, when migrating to `nronn`, generated man page is messed up. https://github.com/rubygems/rubygems/commit/7161347648
2023-12-08[rubygems/rubygems] Revert "Merge pull request #7148 from ↵David Rodríguez
Paul-Bob/improvement/include_response_body_on_fetch_http_error" This reverts commit https://github.com/rubygems/rubygems/commit/e5a4fd9eb617, reversing changes made to https://github.com/rubygems/rubygems/commit/c5a5363b0c98. https://github.com/rubygems/rubygems/commit/e21c45c4c3
2023-12-08Skip to warn like 'bigdecimal/util' feature.Hiroshi SHIBATA
2023-12-08Improve bundled gems warnings for subfeaturesDavid Rodríguez
Before, when requiring "bigdecimal/math" in a Bundler context: > /Users/deivid/.asdf/installs/ruby/3.3.0-dev/lib/ruby/3.3.0+0/bigdecimal/math.rb:2: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. After: > foo.rb:1: warning: bigdecimal/math is found in bigdecimal, which will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.
2023-12-08Improve bundled gem warningsDavid Rodríguez
Before, when requiring "bigdecimal" in a Bundler context: > foo.rb:1: warning: bigdecimal which will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec. After: > foo.rb:1: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.
2023-12-08The SINCE and WARNED hashes take gem names, not featuresDavid Rodríguez
2023-12-08[rubygems/rubygems] Extract generate_index command to ↵Samuel Giddins
rubygems-generate_index gem So generate_index can be implemented with dependencies, such as the compact index Took this approach from feedback in https://github.com/rubygems/rubygems/pull/6853 Running `gem generate_index` by default will use an installed rubygems-generate_index, or install and then use the command from the gem Apply suggestions from code review https://github.com/rubygems/rubygems/commit/fc1cb9bc9e Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
2023-12-08[rubygems/rubygems] Don't memoize in NameTuple lock_nameMartin Emde
The result of this is already memoized and no other NameTuple methods memoize. https://github.com/rubygems/rubygems/commit/b7cce0c64a
2023-12-08[ci skip] comment for commit be1bbd5b7d40ad863ab35097765d3754726bbd54卜部昌平
2023-12-08Thread specific storage APIsKoichi Sasada
This patch introduces thread specific storage APIs for tools which use `rb_internal_thread_event_hook` APIs. * `rb_internal_thread_specific_key_create()` to create a tool specific thread local storage key and allocate the storage if not available. * `rb_internal_thread_specific_set()` sets a data to thread and tool specific storage. * `rb_internal_thread_specific_get()` gets a data in thread and tool specific storage. Note that `rb_internal_thread_specific_get|set(thread_val, key)` can be called without GVL and safe for async signal and safe for multi-threading (native threads). So you can call it in any internal thread event hooks. Further more you can call it from other native threads. Of course `thread_val` should be living while accessing the data from this function. Note that you should not forget to clean up the set data.
2023-12-08[Bug #19877] Flip-flop needs to be direct conditionNobuyoshi Nakada
2023-12-08[rubygems/rubygems] Use `Minitest::TestTask` in a template file for `minitest`Yuji Yaginuma
`minitest` has introduced a rake task for running test on 5.16.0. https://github.com/minitest/minitest/blob/master/History.rdoc#5160--2022-06-14- This has some tasks related to running tests and it's useful for `minitest` user I think. https://github.com/minitest/minitest#rake-tasks- This PR changed to use the task in a template file for `minitest` https://github.com/rubygems/rubygems/commit/7a86d13062
2023-12-07YJIT: Fix on-stack ISEQ comparison for auto_compact (#9164)Takashi Kokubun
2023-12-07[rubygems/rubygems] Use modern hashes consistentlyDavid Rodríguez
https://github.com/rubygems/rubygems/commit/bb66253f2c
2023-12-07Support method calls inside `defined?`Aaron Patterson
This commit supports all kinds of method calls (including methods with parameters) inside `defined?` calls.
2023-12-07RDoc for ComplexBurdetteLamar
2023-12-07Free everything at shutdownAdam Hess
when the RUBY_FREE_ON_SHUTDOWN environment variable is set, manually free memory at shutdown. Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org> Co-authored-by: Peter Zhu <peter@peterzhu.ca>
2023-12-07Added commentJemma Issroff
2023-12-07[PRISM] Account for multiple arguments when compiling ArgumentsNodeJemma Issroff
BreakNode, ReturnNode and NextNode all compile the ArgumentsNode directly, but we weren't accounting for multiple arguments. If there is more than one argument, we need to also emit a newarray instruction to put the arguments onto the stack
2023-12-07Eliminate array allocation for f(1, *a, &arg), f(*a, **kw, &arg), and f(*a, ↵Jeremy Evans
kw: 1, &arg) These are similar to the f(1, *a, &lvar), f(*a, **kw, &lvar) and f(*a, kw: 1, &lvar) optimizations, but they use getblockparamproxy instruction instead of getlocal. This also fixes the else style to be more similar to the surrounding code.
2023-12-07Add benchmark for recent optimization to avoid implicit allocationsJeremy Evans
2023-12-07Prevent modification of splat array inside setup_parameters_complexJeremy Evans
For the following: ``` def f(*a); a end p f(*a, kw: 3) ``` `setup_parameters_complex` pushes `{kw: 3}` onto `a`. This worked fine back when `concatarray true` was used and `a` was already a copy. It does not work correctly with the optimization to switch to `concatarray false`. This duplicates the array on the callee side in such a case. This affects cases when passing a regular splat and a keyword splat (or literal keywords) in a method call, where the method does not accept keywords. This allocation could probably be avoided, but doing so would make `setup_parameters_complex` more complicated.
2023-12-07Eliminate array allocation for f(*a, kw: 1, &lvar) and f(*a, kw: 1, &@iv)Jeremy Evans
Similar to the previous commit, but this handles the block pass case.
2023-12-07Eliminate array allocation for f(*a, kw: 1)Jeremy Evans
In cases where the compiler can detect the hash is static, it would use duphash for the hash part. As the hash is static, there is no need to allocate an array.
2023-12-07Eliminate array allocation for f(*a, **lvar, &lvar) and f(*a, **@iv, &@iv)Jeremy Evans
The compiler already eliminates the array allocation for f(*a, &lvar) and f(*a, &@iv). If that is safe, then eliminating it for f(*a, **lvar) and f(*a, **@iv) as the last commit did is as safe, and eliminating it for f(*a, **lvar, &lvar) and f(*a, **@iv, &@iv) is also as safe.
2023-12-07Eliminate array allocation for f(*a, **lvar) and f(*a, **@iv)Jeremy Evans
The compiler already eliminates the array allocation for f(*a, &lvar) and f(*a, &@iv), and eliminating the array allocation for keyword splat is as safe as eliminating it for block passes.
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-18 20:49:28 +0000