aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [ruby/prism] A couple of small dot enhancementsHEADmasterKevin Newton2023-12-081-5/+9
| | | | https://github.com/ruby/prism/commit/5642a57f39
* [ruby/prism] Hashes need to deoptimize based on their contentsAaron Patterson2023-12-081-1/+1
| | | | | | | | | 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
* [ruby/prism] More closely match CRuby error messagesKevin Newton2023-12-082-16/+16
| | | | https://github.com/ruby/prism/commit/1ed07a0c6d
* Improve Fiber#kill docs and simplify the NEWS entry to let the documentation ↵Benoit Daloze2023-12-082-3/+11
| | | | explain
* Update default gems list at 49cdf063d6275151075ffd94c3d013 [ci skip]git2023-12-081-0/+1
|
* [ruby/set] Bump version to 1.0.4Akinori MUSHA2023-12-081-2/+2
| | | | https://github.com/ruby/set/commit/efc8c8c9f5
* Revert "Skip to warn like 'bigdecimal/util' feature."Hiroshi SHIBATA2023-12-081-3/+0
| | | | This reverts commit 8f6cf72e661e36410848c1451335fd28a32cecdf.
* Pick commit from https://github.com/rubygems/rubygems/pull/7085Hiroshi SHIBATA2023-12-081-1/+2
| | | | Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
* Pick commit from https://github.com/rubygems/rubygems/pull/7227Hiroshi SHIBATA2023-12-081-1/+1
| | | | Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
* [rubygems/rubygems] Migrate documentation to be generated with nronnDavid Rodríguez2023-12-0830-1379/+199
| | | | https://github.com/rubygems/rubygems/commit/55281f0eaa
* [rubygems/rubygems] Add extra blank line to `bundle outdated` docsDavid Rodríguez2023-12-0830-29/+30
| | | | | | | If it's not there, when migrating to `nronn`, generated man page is messed up. https://github.com/rubygems/rubygems/commit/7161347648
* [rubygems/rubygems] Revert "Merge pull request #7148 from ↵David Rodríguez2023-12-081-1/+1
| | | | | | | | | 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
* Skip to warn like 'bigdecimal/util' feature.Hiroshi SHIBATA2023-12-081-0/+3
|
* Improve bundled gems warnings for subfeaturesDavid Rodríguez2023-12-081-6/+6
| | | | | | | | | | 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.
* Improve bundled gem warningsDavid Rodríguez2023-12-081-2/+3
| | | | | | | | | | 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.
* The SINCE and WARNED hashes take gem names, not featuresDavid Rodríguez2023-12-081-2/+5
|
* [rubygems/rubygems] Extract generate_index command to ↵Samuel Giddins2023-12-0810-979/+60
| | | | | | | | | | | | | | | | 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>
* [rubygems/rubygems] Don't memoize in NameTuple lock_nameMartin Emde2023-12-081-6/+5
| | | | | | | The result of this is already memoized and no other NameTuple methods memoize. https://github.com/rubygems/rubygems/commit/b7cce0c64a
* [ci skip] comment for commit be1bbd5b7d40ad863ab35097765d3754726bbd54卜部昌平2023-12-081-5/+105
|
* Thread specific storage APIsKoichi Sasada2023-12-085-0/+114
| | | | | | | | | | | | | | | | | | | | | 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.
* [Bug #19877] Flip-flop needs to be direct conditionNobuyoshi Nakada2023-12-082-19/+24
|
* [rubygems/rubygems] Use `Minitest::TestTask` in a template file for `minitest`Yuji Yaginuma2023-12-083-13/+5
| | | | | | | | | | | | | `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
* YJIT: Fix on-stack ISEQ comparison for auto_compact (#9164)Takashi Kokubun2023-12-072-6/+38
|
* [rubygems/rubygems] Use modern hashes consistentlyDavid Rodríguez2023-12-07262-3114/+3028
| | | | https://github.com/rubygems/rubygems/commit/bb66253f2c
* Support method calls inside `defined?`Aaron Patterson2023-12-072-63/+181
| | | | | This commit supports all kinds of method calls (including methods with parameters) inside `defined?` calls.
* RDoc for ComplexBurdetteLamar2023-12-071-28/+44
|
* Free everything at shutdownAdam Hess2023-12-0727-6/+285
| | | | | | | 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>
* Added commentJemma Issroff2023-12-071-0/+3
|
* [PRISM] Account for multiple arguments when compiling ArgumentsNodeJemma Issroff2023-12-072-3/+29
| | | | | | | 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
* Eliminate array allocation for f(1, *a, &arg), f(*a, **kw, &arg), and f(*a, ↵Jeremy Evans2023-12-071-7/+34
| | | | | | | | | | | 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.
* Add benchmark for recent optimization to avoid implicit allocationsJeremy Evans2023-12-071-0/+13
|
* Prevent modification of splat array inside setup_parameters_complexJeremy Evans2023-12-072-0/+8
| | | | | | | | | | | | | | | | | | | | | | 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.
* Eliminate array allocation for f(*a, kw: 1, &lvar) and f(*a, kw: 1, &@iv)Jeremy Evans2023-12-071-0/+26
| | | | | Similar to the previous commit, but this handles the block pass case.
* Eliminate array allocation for f(*a, kw: 1)Jeremy Evans2023-12-071-0/+23
| | | | | | 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.
* Eliminate array allocation for f(*a, **lvar, &lvar) and f(*a, **@iv, &@iv)Jeremy Evans2023-12-071-0/+24
| | | | | | | | 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.
* Eliminate array allocation for f(*a, **lvar) and f(*a, **@iv)Jeremy Evans2023-12-071-0/+15
| | | | | | 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.
* Eliminate array allocation for f(1, *a, &lvar) and f(1, *a, &@iv)Jeremy Evans2023-12-071-0/+24
| | | | | | | | | | | Due to how the compiler works, while f(*a, &lvar) and f(*a, &@iv) do not allocate an array, but f(1, *a, &lvar) and f(1, *a, &@iv) do. It's probably possible to fix this in the compiler, but seems easiest to fix this in the peephole optimizer. Eliminating this array allocation is as safe as the current elimination of the array allocation for f(*a, &lvar) and f(*a, &@iv).
* Eliminate array allocation for f(1, *a)Jeremy Evans2023-12-071-0/+21
| | | | | | | | | | Due to how the compiler works, while f(*a) does not allocate an array f(1, *a) does. This is possible to fix in the compiler, but the change is much more complex. This attempts to fix the issue in a simpler way using the peephole optimizer. Eliminating this array allocation is safe, since just as in the f(*a) case, nothing else on the caller side can modify the array.
* [PRISM] Stop catch table entries being deleted by the optimiserMatt Valentine-House2023-12-072-9/+5
|
* Support tracing of struct member accessor methodsJeremy Evans2023-12-075-22/+118
| | | | | | | | | This follows the same approach used for attr_reader/attr_writer in 2d98593bf54a37397c6e4886ccc7e3654c2eaf85, skipping the checking for tracing after the first call using the call cache, and clearing the call cache when tracing is turned on/off. Fixes [Bug #18886]
* Skip a flaky objspace test on Visual StudioTakashi Kokubun2023-12-071-0/+1
| | | | | | | | This seems to happen only on VisualStudio: https://github.com/ruby/ruby/actions/runs/7130917319/job/19418375386 It fails relatively frequently. Nobody seems actively working on it, so let's skip it until somebody starts working on it.
* Support eval "return" at toplevelJeremy Evans2023-12-072-1/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since Ruby 2.4, `return` is supported at toplevel. This makes `eval "return"` also supported at toplevel. This mostly uses the same tests as direct `return` at toplevel, with a couple differences: `END {return if false}` is a SyntaxError, but `END {eval "return" if false}` is not an error since the eval is never executed. `END {return}` is a SyntaxError, but `END {eval "return"}` is a LocalJumpError. The following is a SyntaxError: ```ruby class X nil&defined?0--begin e=no_method_error(); return; 0;end end ``` However, the following is not, because the eval is never executed: ```ruby class X nil&defined?0--begin e=no_method_error(); eval "return"; 0;end end ``` Fixes [Bug #19779]
* Use free with ruby_dtoaJohn Hawthorn2023-12-073-3/+3
| | | | | | | In ae0ceafb0c0d05cc80623b525070255e3abb34ef ruby_dtoa was switched to use malloc instead of xmalloc, which means that consumers should be using free instead of xfree. Otherwise we will artificially shrink oldmalloc_increase_bytes.
* Use xfree in hash_st_freeJohn Hawthorn2023-12-071-2/+2
| | | | | | | st.c redefines malloc and free to be ruby_xmalloc and ruby_xfree, so when this was copied into hash.c it ended up mismatching an xmalloc with a regular free, which ended up inflating oldmalloc_increase_bytes when hashes were freed by minor GC.
* Fix keyword splat passing as regular argumentJeremy Evans2023-12-075-21/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since Ruby 3.0, Ruby has passed a keyword splat as a regular argument in the case of a call to a Ruby method where the method does not accept keyword arguments, if the method call does not contain an argument splat: ```ruby def self.f(obj) obj end def self.fs(*obj) obj[0] end h = {a: 1} f(**h).equal?(h) # Before: true; After: false fs(**h).equal?(h) # Before: true; After: false a = [] f(*a, **h).equal?(h) # Before and After: false fs(*a, **h).equal?(h) # Before and After: false ``` The fact that the behavior differs when passing an empty argument splat makes it obvious that something is not working the way it is intended. Ruby 2 always copied the keyword splat hash, and that is the expected behavior in Ruby 3. This bug is because of a missed check in setup_parameters_complex. If the keyword splat passed is not mutable, then it points to an existing object and not a new object, and therefore it must be copied. Now, there are 3 specs for the broken behavior of directly using the keyword splatted hash. Fix two specs and add a new version guard. Do not keep the specs for the broken behavior for earlier Ruby versions, in case this fix is backported. For the ruby2_keywords spec, just remove the related line, since that line is unrelated to what the spec is testing. Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
* Fix typo in a comment [ci skip]Nobuyoshi Nakada2023-12-081-1/+1
|
* Fix potential compaction issue in env_copy()Alan Wu2023-12-071-4/+5
| | | | | | | | | | `src_ep[VM_ENV_DATA_INDEX_ME_CREF]` was read out and held without marking across the allocation in vm_env_new(). In case vm_env_new() ran compaction, an invalid reference could have been written into `copied_env`. It might've been hard to actually produce a crash with this issue due to the pinning marking of the field in rb_execution_context_mark().
* Add missing write barrier to env_copy()Alan Wu2023-12-071-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the following crashed with `vm_assert_env:imemo_type_p(obj, imemo_env)` due to missing a missing WB: o = Object.new def o.foo(n) freeze GC.stress = 1 # inflate block nesting get an imemo_env for each level n.tap do |i| i.tap do |local| return Ractor.make_shareable(-> do local + i + n end) end end ensure GC.stress = false GC.verify_internal_consistency end p o.foo(1)[] By the time the recursive env_copy() call returns, `copied_env` could have aged or have turned greyed, so we need a WB for the `ep[VM_ENV_DATA_INDEX_SPECVAL]` assignment which adds an edge. Fix: 674eb7df7f409099f33da77293d9658e09b470d6
* [ruby/irb] Debugging command warning should not be specific to theStan Lo2023-12-071-1/+1
| | | | | | | `debug` command (https://github.com/ruby/irb/pull/806) https://github.com/ruby/irb/commit/b7b57311cc
* [ruby/prism] Update ordering of integer base flagsKevin Newton2023-12-072-2/+25
| | | | https://github.com/ruby/prism/commit/d711950d5f
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-25 07:12:29 +0000