[pull] master from ruby:master#1231
Merged
Merged
Conversation
If we use out-of-source build and have `${BUILD_DIR}/run.gdb` (by
`make run.gdb`), `${SOURCE_DIR}/.gdbinit` is loaded twice because
`run.gdb` loads `${SOURCE_DIR}/.gdbinit`.
If we have `run.gdb`, we don't need `-x ${SOURCE_DIR}/.gdbinit`.
There is one more problem for `${BUILD_DIR}/run.gdb` and
`${SOURCE_DIR}/.gdbinit`. `source -s misc/gdb.py` in
`${SOURCE_DIR}/.gdbinit` is failed when we use out-of-source build and
`${BUILD_DIR}/run.gdb` because `${SOURCE_DIR}` isn't included in
search path of `source`. If we have `directory $(srcdir)` in
`${BUILD_DIR}/run.gdb`, `source -s misc/gdb.py` works in
`${SOURCE_DIR}/.gdbinit` that is loaded from `${BUILD_DIR}/run.gdb`.
Bumps the github-actions group with 2 updates in the / directory: [actions/checkout](https://github.com/actions/checkout) and [taiki-e/install-action](https://github.com/taiki-e/install-action). Bumps the github-actions group with 1 update in the /.github/actions/setup/directories directory: [actions/checkout](https://github.com/actions/checkout). Updates `actions/checkout` from 7.0.0 to 7.0.1 - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@9c091bb...3d3c42e) Updates `taiki-e/install-action` from 2.83.4 to 2.84.0 - [Release notes](https://github.com/taiki-e/install-action/releases) - [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md) - [Commits](taiki-e/install-action@07b4745...a6b2e2d) Updates `actions/checkout` from 7.0.0 to 7.0.1 - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@9c091bb...3d3c42e) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: 7.0.1 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions - dependency-name: taiki-e/install-action dependency-version: 2.84.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions - dependency-name: actions/checkout dependency-version: 7.0.1 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com>
The empty modules existed only as feature flags for gem_prelude to require the gems at boot. Autoload entries serve the same flag role and also load the gems on direct constant access. gem_prelude now requires 'syntax_suggest' itself, which only loads core_ext, so that the eager require does not trigger the autoload circularly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
[Feature #21951] Defer loading these gems from boot to the first error display. They only decorate Exception#detailed_message, so requiring them at boot is unnecessary overhead. `ruby -e1` with user-installed gems drops from 114.3ms to 30.2ms on Apple M1 Pro, matching the --disable-* flags for the three gems. exc_detailed_message forces the autoload entries once on the first call, only in the main Ractor, and then re-dispatches to pick up the detailed_message decorators the gems prepend. When the first call arrives through an already-prepended decorator, re-dispatching is skipped to avoid decorating twice. The gems are loaded with the C-level require so that displaying an error neither invokes nor depends on Kernel#require monkeypatches. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The decoration gems are loaded lazily on the first error display, which in a pre-forking server happens after fork in each child. That loads their code outside copy-on-write shared memory and busts method caches at runtime when they prepend Exception#detailed_message. Process.warmup, called before the first fork by such servers, now loads them eagerly so the prepended decorators land in shared memory and the cache invalidation happens during boot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
require_decoration_gems is called while an exception is being displayed, so $! holds that exception. rb_protect does not preserve errinfo across the call, and the previous code cleared it to nil whenever a require raised, losing the exception being shown. Save errinfo before the requires and restore it afterward so $! is left untouched whether or not a require fails.
The comment still described loading via a gem_prelude.rb Exception#detailed_message hook, which no longer exists. error.c now loads the gems on the first error, or eagerly via Process.warmup.
rb_require_string delegates requires from non-main Ractors to the main Ractor via rb_ractor_require, so the main-Ractor guard here was unnecessary. Drop it and claim the load with an atomic exchange, because Ractors run in parallel and the plain bool flag was only safe under that guard. did_you_mean already keeps its state Ractor-safe, so suggestions now appear in non-main Ractors as well. Suggested by John Hawthorn.
…ot as its gemspec `gem update --system` wrote the new default bundler gemspec next to the previous one, but extracted its executables under `Gem.default_dir`. On rubies where `Gem.default_specifications_dir` lives under a different root than `Gem.default_dir`, like Homebrew ruby, activating the default bundler then computes an executable path that does not exist, breaking the `bundle` binstub. Extract the executables and remove the previous default gem under the same root as the gemspec instead. ruby/rubygems#9685 ruby/rubygems@04d53913e4 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The default gemspec is already written to the default specifications directory before building the gem, so `installer.write_default_spec` just wrote the same file a second time. Drop the redundant call and let the installer only extract and generate the executables. ruby/rubygems@c69d5ce7c4
…ult dir When a regular gem of the vendored bundler version was already installed, its files were removed from the default gemspec's gems directory instead of from default_dir. On rubies where those roots differ, like Homebrew ruby, the regular gem files were left behind after being promoted to the default gem. Remove them from default_dir, where regular gems actually live. ruby/rubygems@721bcb9691
CacheFile#append opened the temp file with mode "a", which on Windows is a text-mode stream that rewrites every "\n" as "\r\n". The corruption goes undetected because DigestIO hashes the logical bytes handed to write, not the bytes the OS actually lands on disk, so verify passes and the mangled file is committed. The damage compounds on the next update: the extra carriage returns shift file.size, so the ranged request restarts at the wrong offset and the versions index no longer matches its expected digest, forcing a full re-download every time. The info files keep failing their MD5 check against the raw index bytes, so they are refetched on every resolve. Open the append stream with "ab" so the appended range is written verbatim, matching the binary "wb" used for full writes. ruby/rubygems@9568d9600c
The spec calls Dir.mktmpdir in a let block, but neither bundler nor the spec_helper loads tmpdir, so the example raised NoMethodError before running. The sibling updater_spec already requires it explicitly. ruby/rubygems@f9eb1c1b22
CI runs bundler specs with `--tag shard_<x>`, so a spec file that is not listed in spec/support/shards.rb runs in no shard at all. Register the new cache_file_spec.rb under shard_d as the file header instructs. ruby/rubygems@537479a45a
THe downside is that we now always reserve one 8B reference for the IMEMO/fields, even for structs that never have any ivars. But it is an acceptable tradeoff given that ivars on structs aren't rare. Co-Authored-By: John Hawthorn <john@hawthorn.email>
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )