[pull] master from ruby:master - #1385
Merged
Merged
Conversation
Bumps the github-actions group with 1 update in the / directory: [taiki-e/install-action](https://github.com/taiki-e/install-action). Updates `taiki-e/install-action` from 2.87.3 to 2.87.5 - [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@0758d23...5bf6ce0) --- updated-dependencies: - dependency-name: taiki-e/install-action dependency-version: 2.87.5 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com>
mkmf.log and gem_make.out were written into the installed extension directory, polluting the install tree and breaking bit-for-bit reproducibility checks on distros like Guix and Nix. A successful build now leaves no logs behind, and a failed build writes them to build_info (<full_name>.mkmf.log / <full_name>.gem_make.out) for inspection. https://bugs.ruby-lang.org/issues/21995 ruby/rubygems#6259 ruby/rubygems@5c2ef35eed Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Clean up the per-gem mkmf.log and gem_make.out left in build_info by a failed extension build when the gem is uninstalled. ruby/rubygems@ec599546fc Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… installed These specs read the `make -jN` command line from `gem_make.out`, which a successful build no longer writes. The integration specs in `install_spec` now force the build to fail so the command lands in `build_info`, and the `parallel_installer` specs assert on the number of jobserver slots each gem's build acquired, which is exactly what becomes `make -jN`, instead of reading a build log. ruby/rubygems@5d703328c3 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Older system RubyGems writes the build log to the extension directory, so under RGV=system the example read the new build_info path and hit ENOENT. The `-j` suppression it verifies only exists with the jobserver support in RubyGems 4.1, so gate it like its sibling examples. ruby/rubygems@16c69087b6 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two behaviours regressed against the extension directory the logs used to live in. "clean" is the first make target and mkmf lists mkmf.log in CLEANFILES, so the log was already gone by the time a compile failure reached the handler that moves it to build_info. And nothing cleared a failed build's logs afterwards, where previously the installer wiped the extension directory on every install, so a later successful install kept reporting an old failure. Park mkmf.log next to the built extension right after extconf, the way ExtConfBuilder did before, and let build_extension decide from there whether to drop it or keep it. Drop both logs again on success, along with any gem_make.out an older RubyGems left in the extension directory. ruby/rubygems@47614894cf Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
build_info entries are matched by stripping ".info", so the new <full_name>.mkmf.log and <full_name>.gem_make.out never matched an installed gem and were removed as strays, including the log the build error had just told the user to read. Let a subdirectory declare several suffixes and give build_info all three. ruby/rubygems@d1b3845795 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Logs for a git source land in bundler/gems/build_info, which `bundle clean` globs as a git checkout and reports as "Removing (build_info)" before deleting it. Exclude it the way the sibling extensions directory already is. ruby/rubygems@01dfc59016 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Preserving a log happens while a build failure is being reported, so a filesystem error there replaced the compile output the user needed with a bare Errno, and the extension builder stopped raising Gem::Ext::BuildError at all. Callers only rescue the Gem::InstallError family, so the failure escaped as an unhandled exception. Swallow errors from moving mkmf.log and from writing gem_make.out, and drop the "Results logged to" line when there is no log to point at. ruby/rubygems@c5f4887ac7 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
An extconf that exits cleanly without generating a Makefile leaves the extension unbuilt while the install still reports success. That case used to be described in gem_make.out; since the success path stopped writing one it went unrecorded entirely. Let the no-Makefile case reach Gem::Ext::Builder, which already owns where logs end up, and have it write the explanation to build_info. ruby/rubygems@e183327d52 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
base_dir for a git source points at the directory holding every checkout, so logs keyed by full_name collided between revisions of the same gem and landed in bundler/gems/build_info, which nothing prunes and which `bundle clean` mistook for a stale checkout. Resolve them from extension_dir instead, which Bundler already makes unique per revision and which `bundle clean` removes along with the checkout. That also drops the clean exclusion added for the directory this no longer creates. Path sources are unaffected: Bundler installs them with extensions disabled, so they never produce a build log. ruby/rubygems@71b4dbc584 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The git extension spec overwrote the C source after build_git had already committed the checkout, so bundle installed the original working source and the build succeeded, leaving no log to find. Write the broken source inside the build_git block, and assert the log is the one this failure produced. ExtConfBuilder no longer swallows NoMakefileError, so on JRuby, where the fixture extconf returns before creating a Makefile, calling the class method directly now raises instead of returning. ruby/rubygems@d8616f348d Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Where a build log goes is decided by the RubyGems running the install, and under RGV=system that is an older one which writes a bare gem_make.out into the extension directory. Gate the example the way the other specs that assert on log locations already are. ruby/rubygems@fca2ce60e8 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
[Bug #21977] When `RUBY_BOX=1` is set, combining `binding` with `Symbol#to_proc` causes a crash (`[BUG] BUG: Local ep without cme/box`). This occurs because escaping an `IFUNC` frame via `binding` adds the `VM_ENV_FLAG_LOCAL` flag. `VM_EP_RUBY_LEP` previously relied on `VM_EP_LEP`, which blindly stopped at this flag. This caused it to return the `IFUNC` itself instead of its caller, and since `IFUNC` lacks `cme/box` data, the Box resolution crashed. This commit fixes the issue by traversing `current_cfp` backwards to skip `IFUNC` frames directly, instead of relying on `VM_EP_LEP` and the local flag.
An ifunc proc created by Method#to_proc and invoked directly via Proc#call has no enclosing CFUNC frame. The IFUNC skip loop in VM_EP_RUBY_LEP returned the caller's ep unconditionally, so a non-local EVAL ep reached current_box_on_cfp and crashed with "BUG: Local ep without cme/box". Return the ep early only when the enclosing frame is a CFUNC, and otherwise continue to the local ep walk. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…tor_child recursion doctor_child took a single extension when the ABI-scoped recursion was written, and gained a splat in the same release, so the recursion has been raising NameError on any repository with a specifications/<abi> directory. ruby/rubygems@4fd406f68a Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… resolve The content addressing resolver tests built a "~> X.Y.0" requirement from the running Ruby, which a prerelease Ruby does not satisfy, so both tests failed on 4.1.0dev. Reuse the pinning the dependency installer test already did for the same reason. ruby/rubygems@ddaf343ade Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… test output Three tests feed rubygems something they expect it to reject: two write a gemspec that cannot be loaded, one asks git for a ref that does not exist. Each printed its diagnosis straight into the middle of the test run, as did the rake package task that no longer silenced FileUtils. ruby/rubygems@89cc731c85 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SimpleCov writes its summary to stderr, so the redirection meant to keep the collate quiet never caught it and every run ended with the same two lines twice. A failing run replaced the second copy with SimpleCov reporting that it had stopped, which reads like a third failure. ruby/rubygems@254b0332c2 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
[Bug #22015] During a normal method call, the VM creates a control frame, and the Ruby::Box associated with that frame determines the execution context. However, Symbol#to_proc does not automatically create a frame. Therefore, we need to manually push a frame associated with the appropriate Box context. When determining the Box to associate with this new frame, we cannot simply look at the closest Ruby-level control frame. This is because some built-in methods (like `Enumerable#map`) are implemented in Ruby (e.g., `<internal:enum>`). These built-in Ruby frames belong to the default Root or Main Box, which would obscure the actual user-defined Box context we need to capture. To fix this properly, we now traverse the frames and check their inherent Box states. Since built-in Ruby frames always run in the Root or Main Box, we safely skip them by continuing our traversal until we find a user-defined Box (an Optional Box, indicated by `BOX_OPTIONAL_P`).
Remove comments that lost context after the final changes.
Since the main/root box separation ([Feature #21881]), code running in the main box also fails to call box-local methods via Symbol#to_proc. Stop the caller-frame traversal at any user box (main or optional) instead of optional boxes only.
Per review feedback, a TOP frame in the middle of a method call is misleading. Push a VM_FRAME_MAGIC_BLOCK frame whose outer env points to the caller's frame, so the box resolves through the ep chain and the backtrace reads like a usual block invocation at the caller's site. The frame is finished but owned by no vm_exec loop, so catch the non-local exit and rewind to the caller before re-raising. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
3 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 : )