[pull] master from ruby:master - #1369
Merged
Merged
Conversation
I tried fixing the test for a bit but it's not clear to me what the test expects. Skip for now; I've pinged the author.
Fixes a compiler warning:
In file included from ../vm.c:676:
../vm_insnhelper.c: In function ‘rb_zjit_throw’:
../vm_insnhelper.c:1886:1: warning: function might be candidate for attribute ‘noreturn’ [-Wsuggest-attribute=noreturn]
1886 | rb_zjit_throw(rb_execution_context_t *ec, rb_control_frame_t *reg_cfp, rb_num_t throw_state, VALUE throwobj)
| ^~~~~~~~~~~~~
We need to call more and have more classes for this test to make sense.
No one was actually doing equality comparison on `FrameState`s and it was only derived because `FrameState` was in `ParseError::StackUnderflow`. No one was reading the `FrameState` out of `StackUnderflow` either. Save some binary size.
`s` is the current string pointer (`self`), `t` is the new buffer pointer initialized with `malloc / realloc`. Hence this condition is always true.
(ruby/time#76) The sample code and its result in the Time.rfc2822 documentation appear to be inconsistent. ruby/time@b602d284aa
- Normalizes legacy Latin-1 bytes in Gem::Specification.normalize_yaml_input. - Works with both Psych and RubyGems’ internal YAML parser. ruby/rubygems@76215364df
Fall back to RubyGems' safe YAML parser when Psych cannot accept the metadata as UTF-8. This preserves bytes from ISO-8859-1, EUC-JP, and other legacy encodings without guessing their encoding. ruby/rubygems@503e144810
On GitHub Actions the push tests inherited the real variable, took the auto-attestation path, and spawned `gem exec sigstore-cli` subprocesses. Scrubbing it in setup also made the host and engine skip guards decide nothing, so those tests now set it themselves. ruby/rubygems@8f4bb82839 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
GitHub Actions documents the variable as "true", so any other value, including "false", should not trigger the auto-attestation path. ruby/rubygems@f6b15f8b45 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The whole attested push was wrapped in rescue StandardError. A failure to read a file given to --attestation printed a warning and published the gem unattested with exit 0, and a network error after the server may have accepted the multipart push retried it unattested, letting an on-path attacker strip attestations by cutting the first connection. Only the opportunistic auto-signing step falls back now. attest! also returned just the tempfile path, so GC could unlink the bundle before it was read, which fell into that same rescue. Each bundle is now validated as a JSON object before it is sent. ruby/rubygems@9ce35a5f21 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ne is gone A git source that pins no branch, tag or ref follows whatever branch the cached bare clone's HEAD points at. Once the remote renames its default branch that fetch fails, and `Source::Git#fetch` swallowed the failure as a network error, so the lockfile stayed pinned to the old revision and `bundle update` reported success with nothing to explain it. Ask the remote for its current default branch on that failure, fetch it, and repoint the cached clone. Anything that goes wrong in there leaves HEAD alone and lets the caller report the original failure, since the cache is shared with every other project on the machine using the same URI, and a half-moved cache would never heal on its own. Fixes ruby/rubygems#5810. ruby/rubygems@5831d9cccb Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A gem installed from a local path was copied into the global cache under its canonical file name, where later remote installs of the same name and version would reuse it without re-verification, so one local install could poison every other project on the machine. Two smaller problems in the same expression go with it. The global cache branch was evaluated before the one gem fetch relies on, so gem fetch wrote into the cache instead of the working directory, and an unwritable cache directory aborted the install rather than falling back the way it does with the cache disabled. The working directory is compared by identity because the paths can differ while naming the same place, and because Dir.pwd raises once that directory is gone. ruby/rubygems@645fe42ef9 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The file and path schemes wrote into the shared cache directory with a plain FileUtils.cp, so a concurrent install could read a half-written .gem file. Route them through Gem::AtomicFileWriter like the http scheme, which also makes replacing a read-only cache copy work. cp passed the source mode to File.open, so it reached only a file being created and the umask still applied to it. Reproduce that rather than chmodding unconditionally, which would skip the umask, carry setuid across, and rewrite the mode of a file cp would have left alone. ruby/rubygems@9507af2bf3 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… the API The expected cache base was computed from Gem.global_gem_cache_path, the same expression the code under test uses, so the assertion could never catch an unintended path change. That method was added after 4.0 was cut, so no released 4.0.x has it and the old gate would make the specs expect the RubyGems layout from a Bundler that falls back to its own. ruby/rubygems@ca3c7c08b7 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
It was deprecated in 4.0 with a 4.1 removal horizon, and its tests were already dropped with the deprecation. Nothing else in this file uses `rubygems_deprecate`, so the `Gem::Deprecate` extension goes too. ruby/rubygems@a0b5cb5e03 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Bumps the github-actions group with 2 updates in the / directory: [zizmorcore/zizmor-action](https://github.com/zizmorcore/zizmor-action) and [taiki-e/install-action](https://github.com/taiki-e/install-action). Updates `zizmorcore/zizmor-action` from 0.6.2 to 0.6.3 - [Release notes](https://github.com/zizmorcore/zizmor-action/releases) - [Commits](zizmorcore/zizmor-action@3dc1ecc...70fb788) Updates `taiki-e/install-action` from 2.87.1 to 2.87.2 - [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@742a331...1ed6d7b) --- updated-dependencies: - dependency-name: zizmorcore/zizmor-action dependency-version: 0.6.3 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions - dependency-name: taiki-e/install-action dependency-version: 2.87.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com>
When bundle exec resolves an explicit relative path like ./script and falls back to Kernel.exec, Bundler currently prepends another ./ because the resolved path is not absolute. The same issue affects Windows paths such as .\script. Only prepend ./ for non-absolute paths that do not already begin with an explicit relative path marker. Recognize the platform's alternative path separator without changing the meaning of backslashes on POSIX. Add integration coverage for the original regression and focused coverage for primary and alternative path separators. Closes ruby/rubygems#8930 Assisted-By: devx/caa7d694-19ff-42bb-9306-686cb9d69649 ruby/rubygems@d172a35a54
We don't need 64 bits for jit_entry_calls/jit_exception_calls so dropping them down to 32 bits will allow us to save 8 bytes per iseq.
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.
11 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 : )