summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-11-13GVL Instrumentation: pass thread->self as part of event dataJean Boussier
Context: https://github.com/ivoanjo/gvl-tracing/pull/4 Some hooks may want to collect data on a per thread basis. Right now the only way to identify the concerned thread is to use `rb_nativethread_self()` or similar, but even then because of the thread cache or MaNy, two distinct Ruby threads may report the same native thread id. By passing `thread->self`, hooks can use it as a key to store the metadata. NB: Most hooks are executed outside the GVL, so such data collection need to use a thread-safe data-structure, and shouldn't use the reference in other ways from inside the hook. They must also either pin that value or handle compaction.
2023-11-13[DOC] Close a tagNobuyoshi Nakada
2023-11-13[DOC] Fix Timezone Objects descriptionNobuyoshi Nakada
From the beginning when Timezone object support was introduced, Timezone objects are allowed everywhere offset strings are allowed.
2023-11-13make-snapshot: update RUBY_PATCHLEVEL_STR regexpSorah Fukumori
the regexp to replace RUBY_PATCHLEVEL_STR for prerelease snapshots doesn't match since GH-8578. follow-up: https://github.com/ruby/ruby/pull/8578 follow-up: 68df43788dc237a1071f02b2d82768f844696315
2023-11-13[rubygems/rubygems] Explicitly define `@default_specifications_dir` for testsVít Ondruch
Resetting `@default_specifications_dir` to `nil` means that the `Gem.default_specifications_dir` needs to be invoked. However, given that this method might be overridden by operating_system.rb and similar, this might lead to various test failures. Providing the default value makes the issues go away. https://github.com/rubygems/rubygems/commit/59626cb650
2023-11-13[rubygems/rubygems] Provide more insightful test error outputVít Ondruch
Original output: ~~~ Failure: test_realworld_upgraded_default_gem(TestGemRequire): <false> is not true. /mnt/test/rubygems/test_require.rb:474:in `test_realworld_upgraded_default_gem' 471: File.write(path, code) 472: 473: output = Gem::Util.popen({ "GEM_HOME" => @gemhome }, *ruby_with_rubygems_in_load_path, path).strip => 474: assert $?.success? 475: refute_empty output 476: assert_equal "999.99.9", output.lines[0].chomp 477: # Make sure only files from the newer json gem are loaded, and no files from the default json gem ~~~ New output: ~~~ Failure: test_realworld_upgraded_default_gem(TestGemRequire) /mnt/test/rubygems/test_require.rb:475:in `test_realworld_upgraded_default_gem' 472: 473: output = Gem::Util.popen({ "GEM_HOME" => @gemhome }, *ruby_with_rubygems_in_load_path, path).strip 474: refute_empty output => 475: assert_equal "999.99.9", output.lines[0].chomp 476: # Make sure only files from the newer json gem are loaded, and no files from the default json gem 477: assert_equal ["#{@gemhome}/gems/json-999.99.9/lib/json.rb"], output.lines.grep(%r{/gems/json-}).map(&:chomp) 478: assert $?.success? <"999.99.9"> expected but was <"/mnt/tmp/test_rubygems_20231110-36663-of405r/test_realworld_upgraded_default_gem.rb:3:in `<main>': undefined method `version' for nil:NilClass (NoMethodError)"> diff: ? 999 .99.9 ? /mnt/tmp/test_rubygems_20231110-36663-of405r/test_realworld_upgraded_default_gem rb:3:in `<main>': undefined method `version' for nil:NilClass (NoMethodError) ? ??? ???? ~~~ It is more valuable to check the command output then the error code. If the command fails for some reason, the output probably contains some detail, while checking the return code tells not much. https://github.com/rubygems/rubygems/commit/b76062e852
2023-11-13[rubygems/rubygems] Add a warning in an edge case of using `gemspec` DSLDavid Rodríguez
If a Gemfile duplicates a development dependency also defined in a local gemspec with a different requirement, the requirement in the local gemspec will be silently ignored. This surprised me. I think we should either: * Make sure both requirements are considered, like it happens for runtime dependencies (I added a spec to illustrate the current behavior here). * Add a warning that the requirement in the gemspec will be ignored. I think the former is slightly preferable, but it may cause some bundle's that previously resolve to no longer resolver. I went with the latter but the more I think about it, the more this seems like it should behave like the former. https://github.com/rubygems/rubygems/commit/ad6843972f
2023-11-13[rubygems/rubygems] This can be frozen nowDavid Rodríguez
https://github.com/rubygems/rubygems/commit/d06544add2
2023-11-13[rubygems/rubygems] Remove now unnecessary dupsDavid Rodríguez
https://github.com/rubygems/rubygems/commit/56ce2a6445
2023-11-13[rubygems/rubygems] Remove now unnecessary dupDavid Rodríguez
https://github.com/rubygems/rubygems/commit/3c1a6a7dfa
2023-11-13[rubygems/rubygems] Add a note about `required_rubygems_version` in BundlerDavid Rodríguez
https://github.com/rubygems/rubygems/commit/9509d98b5c
2023-11-13[rubygems/rubygems] Let RuboCop target Ruby 3.0David Rodríguez
https://github.com/rubygems/rubygems/commit/70243b1d72
2023-11-13[rubygems/rubygems] Drop support for Ruby 2.6 and Ruby 2.7 in BundlerDavid Rodríguez
https://github.com/rubygems/rubygems/commit/93619c97ff
2023-11-13[rubygems/rubygems] Drop support for Ruby 2.6 and Ruby 2.7 in RubyGemsDavid Rodríguez
https://github.com/rubygems/rubygems/commit/10c26a483d
2023-11-13[rubygems/rubygems] Automatically lock extra ruby platformsDavid Rodríguez
Since we started locking the specific platform in the lockfile, that has created an annoying situation for users that don't develop on Linux. They will create a lockfile on their machines, locking their local platform, for example, darwin. But then that lockfile won't work automatically when deploying to Heroku for example, because the lockfile is frozen and the Linux platform is not included. There's the chance though that resolving against two platforms (Linux + the local platform) won't succeed while resolving for just the current platform will. So, instead, we check other platform specific variants available for the resolution we initially found, and lock those platforms and specs too if they satisfy the resolution. This is only done when generating new lockfiles from scratch, existing lockfiles should keep working as before, and it's only done for "ruby platforms", i.e., not Java or Windows which have their own complexities, and so are excluded. With this change, we expect that MacOS users can bundle locally and deploy to Heroku without needing to do anything special. https://github.com/rubygems/rubygems/commit/5f24f06bc5
2023-11-13[rubygems/rubygems] Refactor platform test helpersDavid Rodriguez
https://github.com/rubygems/rubygems/commit/7ab4c203f9
2023-11-13[rubygems/rubygems] Extract builder to create a `LazySpecification` from ↵David Rodríguez
full spec https://github.com/rubygems/rubygems/commit/957d3d9a7f
2023-11-13[rubygems/rubygems] Extract a new small platform helperDavid Rodríguez
https://github.com/rubygems/rubygems/commit/8f7340df8e
2023-11-13[rubygems/rubygems] Remove unused `SpecSet#merge`David Rodríguez
https://github.com/rubygems/rubygems/commit/53e0490b55
2023-11-13[rubygems/rubygems] Pass source to `LazySpecification` initializerDavid Rodríguez
https://github.com/rubygems/rubygems/commit/05120e2fe8
2023-11-13[rubygems/rubygems] Allow setting metadata on LazySpecificationDavid Rodríguez
This is a step forward towards eventually including metadata in the lockfile. https://github.com/rubygems/rubygems/commit/56fc02b251
2023-11-13[rubygems/rubygems] Set LazySpecification dependencies directlyDavid Rodríguez
https://github.com/rubygems/rubygems/commit/2462c8e04d
2023-11-13[rubygems/rubygems] Report possible error prior checking output of gem uninstallVít Ondruch
Originally, the failed test case reported following error: ~~~ Failure: test_gem_exec_gem_uninstall(TestGemCommandsExecCommand): <""> was expected to include <"Successfully uninstalled a-2\n">. /mnt/test/rubygems/test_gem_commands_exec_command.rb:742:in `block in test_gem_exec_gem_uninstall' 739: 740: # assert_empty @ui.error 741: refute_includes @ui.output, "running gem exec with" => 742: assert_includes @ui.output, "Successfully uninstalled a-2\n" 743: 744: invoke "--verbose", "gem", "uninstall", "b" 745: assert_includes @ui.output, "Successfully uninstalled b-2\n" /mnt/lib/rubygems/user_interaction.rb:46:in `use_ui' /mnt/lib/rubygems/user_interaction.rb:69:in `use_ui' /mnt/test/rubygems/test_gem_commands_exec_command.rb:726:in `test_gem_exec_gem_uninstall' ~~~ This does not tell much. Empty string is more often good sign, but not in this case. However, checking error output first helps with understanding possible issue: ~~~ Failure: test_gem_exec_gem_uninstall(TestGemCommandsExecCommand): <"ERROR: While executing gem ... (Gem::FilePermissionError)\n" + " You don't have write permissions for the /builddir/bin directory.\n" + "\t/mnt/lib/rubygems/uninstaller.rb:213:in `remove_executables'\n" + ... snip ... /mnt/test/rubygems/test_gem_commands_exec_command.rb:740:in `block in test_gem_exec_gem_uninstall' 737: nil 738: end 739: => 740: assert_empty @ui.error 741: refute_includes @ui.output, "running gem exec with" 742: assert_includes @ui.output, "Successfully uninstalled a-2\n" 743: /mnt/lib/rubygems/user_interaction.rb:46:in `use_ui' /mnt/lib/rubygems/user_interaction.rb:69:in `use_ui' /mnt/test/rubygems/test_gem_commands_exec_command.rb:726:in `test_gem_exec_gem_uninstall' ~~~ BTW this issue is caused by operating_system.rb overriding `Gem.operating_system_defaults` method and explicitly adding `--bindir` option. https://github.com/rubygems/rubygems/commit/d98e36bbe7
2023-11-12Fix crash caused by concurrent ObjectSpace.dump_all callsKJ Tsanaktsidis
Since the callback defined in the objspace module might give up the GVL, we need to make sure the right cr->mfd value is set back after the GVL is re-obtained.
2023-11-12Wrap rb_objspace_reachable_objects_from_root with RB_VM_LOCKKJ Tsanaktsidis
rb_objspace_reachable_objects_from has it too, so I figure it's most likely required for _from_root as well.
2023-11-12Just check if iteration level is non-zerov3_3_0_preview3Nobuyoshi Nakada
The level in ivar is no longer needed to check if iterating, only used for increment/decrement.
2023-11-12Refactor hash iteration levelNobuyoshi Nakada
- Make it unsigned like as in-flags bits - Make it long since it should be fixable - Reduce it to in-flags bits after decrement
2023-11-12[ruby/prism] Add the ability to convert nodes to dotKevin Newton
https://github.com/ruby/prism/commit/3e4b4fb947
2023-11-12[ruby/prism] Reject invalid rational literals like `1e1r` on lexingTSUYUSATO Kitsune
Fix https://github.com/ruby/prism/pull/1586 https://github.com/ruby/prism/commit/b3bde866f2
2023-11-11[ruby/prism] Implement JavaScript visitorsMarco Roth
https://github.com/ruby/prism/commit/ea00a1b3c6
2023-11-11[ruby/prism] Introduce non-associativility to `in` and `=>`TSUYUSATO Kitsune
Fix https://github.com/ruby/prism/pull/1596 Fix https://github.com/ruby/prism/pull/1771 Close https://github.com/ruby/prism/pull/1773 https://github.com/ruby/prism/commit/a3413e5605
2023-11-11[DOC] Update comment for `DECIMAL_SIZE_OF_BITS`Nobuyoshi Nakada
2023-11-11[Bug #19969] Compact st_table after deleted if possibleNobuyoshi Nakada
2023-11-11Stabilize outer variable listNobuyoshi Nakada
Sort outer variables by names to make dumped binary data stable.
2023-11-11RCLASS_EXT is never NULL nowNobuyoshi Nakada
2023-11-10[DOC] RubyVM::YJIT doc improvementsAlan Wu
* Weaken notice about API stability. A few public APIs in here now. * Prune out APIs from the docs that are private in nature * Enable markdown mode and ensure `--` options are quoted so they are rendered as two dashes in the HTML.
2023-11-10[DOC] NEWS.md update about code GCAlan Wu
See <https://github.com/ruby/ruby/pull/8865> and 50402db5a7d3bb2a9a93d63a63295b4d85a68088
2023-11-10YJIT: Fix `clippy::useless_vec` in a testAlan Wu
2023-11-10YJIT: Take cargo --fix for unnecessary calls to into()Alan Wu
2023-11-10YJIT: Auto fix for clippy::unnecessary_castAlan Wu
2023-11-10YJIT: Auto fix for clippy::clone_on_copyAlan Wu
2023-11-10[ruby/prism] Remove extra locals added by ...Kevin Newton
https://github.com/ruby/prism/commit/b7850f2d30
2023-11-10[ruby/prism] Disallow forwarding in blocksKevin Newton
https://github.com/ruby/prism/commit/2bbd35943c
2023-11-10[ruby/prism] Add source code and changelog urisMateus Pereira
https://github.com/ruby/prism/commit/33a85f7867
2023-11-10Update default gems list at 8044feb7ab75989d5c8bd40131801e [ci skip]git
2023-11-10[ruby/irb] Bump version to 1.9.0ima1zumi
(https://github.com/ruby/irb/pull/757) https://github.com/ruby/irb/commit/41548b8bd0
2023-11-10[ci skip] Fix indentation in rb_class_ivar_setPeter Zhu
2023-11-10[ruby/open3] [DOC] RDoc for Open3Burdette Lamar
(https://github.com/ruby/open3/pull/18) https://github.com/ruby/open3/commit/9f3f5d004c
2023-11-10YJIT: Panic with more info when global invalidation patching failsAlan Wu
2023-11-10YJIT: Invoke PosMarker callbacks only with solid positionsAlan Wu
Previously, PosMarker callbacks ran even when the assembler failed to assemble its contents due to insufficient space. This was problematic because when Assembler::compile() failed, the callbacks were given positions that have no valid code, contrary to general expectation. For example, we use a PosMarker callback to record VM instruction boundaries and patch in jumps to exits in case the guest program starts tracing, however, previously, we could record a location near the end of the code block, where there is no space to patch in jumps. I suspect this is the cause of the recent occurrences of rare random failures on GitHub Actions with the invariants.rs:529 "can rewrite existing code" message. `--yjit-perf` also uses PosMarker and had a similar issue. Buffer the list of callbacks to fire, and only fire them when all code in the assembler are written out successfully. It's more intuitive this way.
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-22 15:04:15 +0000