| Age | Commit message (Collapse) | Author |
|---|
|
The Resolver-only hook reshapes deps just before PubGrub sees them,
but it does not influence the Bundler::Dependency objects fed into
Definition#expanded_dependencies. As a result the
Resolver::Package built from each direct dep keeps the original
requirement, so its prerelease policy and (in later commits) lockfile
change detection ignore the override entirely. Apply the override to
direct deps at expanded_dependencies as well so that Package metadata
and convergence see the effective requirement; the Resolver hook
remains responsible for transitive deps fetched from gemspecs.
https://github.com/ruby/rubygems/commit/6f397af4cc
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Pass the Definition's overrides through to Resolver::Base and rewrite
each dependency's requirement at the entry of to_dependency_hash so
both direct and transitive deps are reshaped before PubGrub sees them.
The hook is the same point Shopify/bundler-ignore-dependency uses,
since prepare_dependencies and the @cached_dependencies closure both
funnel through to_dependency_hash. Override#apply_to handles all
three operation kinds, so :ignore_upper and nil also start working
from this commit; integration coverage for those paths follows in
later commits.
https://github.com/ruby/rubygems/commit/93b1c5b46c
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Two override statements that target the same gem and the same field
make it ambiguous which operation should win. Raise ArgumentError
when the new (target, field) pair already exists in the recorded
overrides, leaving the previously recorded entry untouched.
https://github.com/ruby/rubygems/commit/1c90030cf9
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Reject anything other than :all or a String for the target,
fields outside `:version`, and operations that are not a String,
nil, or one of the supported Symbol values (currently only
:ignore_upper). Validation runs before any Override is recorded so
that a multi-field call with an invalid entry leaves the DSL state
untouched.
https://github.com/ruby/rubygems/commit/c3b7aeb6b9
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Version requirements are per-gem and have no meaning relative to the
`:all` target. Raise ArgumentError at the DSL entry point and store
nothing when this combination is given, even if other valid fields
are mixed in the same call.
https://github.com/ruby/rubygems/commit/aabf71f46f
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Switch remove_upper_bounds from a lower-bound allow-list to an
upper-bound reject-list so that operators other than <, <=, and ~>
are kept verbatim. The previous logic, inherited from
Shopify/bundler-ignore-dependency, dropped != exclusions and could
silently re-allow versions the user had explicitly pinned out
(e.g. >= 1.0, != 1.5.0, < 2.0 collapsed to >= 1.0).
https://github.com/ruby/rubygems/commit/7d73d9e035
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Introduce Gemfile-level `override target, field: operation, ...` that
collects Bundler::Override instances and forwards them to Definition
via to_definition. Validation and resolver hookup come in later
commits; this commit only wires the entry point.
https://github.com/ruby/rubygems/commit/e2fc49141c
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Reserve a slot on Definition for the upcoming Gemfile `override` DSL.
This commit only stores the data; the DSL entry point and the resolver
hookup come in later commits.
https://github.com/ruby/rubygems/commit/6fb2bf90fe
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Introduce a value object that holds a target/field/operation triple
for the upcoming Gemfile `override` DSL. apply_to dispatches on the
operation: a version spec string replaces the requirement absolutely,
:ignore_upper strips < and <= while folding ~> into >=, and nil
collapses to Gem::Requirement.default. The :ignore_upper logic is
taken from Shopify/bundler-ignore-dependency.
https://github.com/ruby/rubygems/commit/4c2cafa4e8
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
https://github.com/ruby/rubygems/commit/2a47650f64
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Bundler::LockfileParser#initialize silently accepted any string input,
including Gemfiles or arbitrary text, producing an empty parser with
no indication that the input was invalid. This caused downstream
tooling like bundler-audit to operate on unvalidated content.
Detect non-lockfile content by checking for any of the known section
headers; empty input is left untouched for backward compatibility.
Rather than raising immediately, emit a deprecation warning via
SharedHelpers.feature_deprecated! announcing that a future Bundler
version will raise LockfileError. Expose LockfileParser#valid? so
callers can branch on the result without string-matching the message.
Fixes https://github.com/ruby/rubygems/pull/8932
https://github.com/ruby/rubygems/commit/7607fe4a5d
|
|
```
compiling ../imemo.c
../imemo.c:563:20: warning: unused variable 'shape_id' [-Wunused-variable]
563 | shape_id_t shape_id = RBASIC_SHAPE_ID((VALUE)fields);
| ^~~~~~~~
1 warning generated.
```
|
|
https://github.com/ruby/rubygems/commit/c01e3b9990
|
|
Bumps the rb-sys group with 1 update in the /test/rubygems/test_gem_ext_cargo_builder/custom_name/ext/custom_name_lib directory: [rb-sys](https://github.com/oxidize-rb/rb-sys).
Bumps the rb-sys group with 1 update in the /test/rubygems/test_gem_ext_cargo_builder/rust_ruby_example directory: [rb-sys](https://github.com/oxidize-rb/rb-sys).
Updates `rb-sys` from 0.9.125 to 0.9.127
- [Release notes](https://github.com/oxidize-rb/rb-sys/releases)
- [Commits](https://github.com/oxidize-rb/rb-sys/compare/v0.9.125...v0.9.127)
Updates `rb-sys` from 0.9.125 to 0.9.127
- [Release notes](https://github.com/oxidize-rb/rb-sys/releases)
- [Commits](https://github.com/oxidize-rb/rb-sys/compare/v0.9.125...v0.9.127)
---
updated-dependencies:
- dependency-name: rb-sys
dependency-version: 0.9.127
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: rb-sys
- dependency-name: rb-sys
dependency-version: 0.9.127
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: rb-sys
...
Signed-off-by: dependabot[bot] <support@github.com>
https://github.com/ruby/rubygems/commit/79a46384f1
|
|
Fix https://hackerone.com/reports/3716987
https://github.com/ruby/stringio/commit/4ed1d6b7cf
|
|
https://github.com/ruby/stringio/commit/efe8351676
|
|
Bumps the github-actions group with 1 update in the / directory: [actions/labeler](https://github.com/actions/labeler).
Updates `actions/labeler` from 6.0.1 to 6.1.0
- [Release notes](https://github.com/actions/labeler/releases)
- [Commits](https://github.com/actions/labeler/compare/634933edcd8ababfe52f92936142cc22ac488b1b...f27b608878404679385c85cfa523b85ccb86e213)
---
updated-dependencies:
- dependency-name: actions/labeler
dependency-version: 6.1.0
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: github-actions
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
|
|
Without this patch, there are multiple issues when defining a zsuper
method via a refinement. These issues are due to the orig_me entry
for the zsuper method not being updated when the method it refers
to is modified via:
* Method being redefined (in same or closer ancestor)
* Method being removed
* Method being undef-ed (in same or closer ancestor)
* Method being overridden by method in included module
* Method being overridden by method in prepended module
* Method being defined in an included/prepended module at time of
refinement
This includes a comprehensive test suite for these cases, using both
zsuper methods and iseq methods that call super. Without the changes
to refinement method lookup, the following types of errors occur for
refinement zsuper methods (all of the iseq methods that call super
work correctly with or without these changes):
* Incorrect result (not returning result of expected method, not
raising NoMethodError if the method was removed or has been undef-ed)
* SystemStackError: stack level too deep
* NotImplementedError: false() function is unimplemented on this machine
This avoids the issues with refinement zsuper lookup by turning the
zsuper into a cfunc that uses rb_call_super_kw. This is not a perfect
solution, for two reasons:
* cfuncs are slower than zsuper
* arity/parameters for the method not as helpful (you
It may possible to avoid these issues by clearing method caches in
more cases. However, I think that would require a lot of extra work,
since you cannot just clear the method cache for the current class.
You would need to clear it for all subclasses that are refined, and
if this is a module, do the same for all classes that include/prepend
the module, as well as any subclasses of those classes.
Considering the need for refinement zsuper methods is very rare, the
performance and arity/parameters issues seem acceptable (to me).
Fixes [Bug #22022]
|
|
|
|
Replace `sleep 0.1` with `IO.select([@r])` to reliably wait for data
to arrive before asserting readability with a zero timeout. The fixed
sleep was insufficient on slow Windows CI runners, causing sporadic
failures. This matches the approach already used in test_wait_readable.
https://github.com/ruby/io-wait/commit/dd32ec3682
|
|
|
|
|
|
|
|
|
|
The interpreter may fire the `rb_zjit_invalidate_no_ep_escape` callback multiple times for the same ISEQ. The first one will process all patch points so subsequent processing is unnecessary. Consuming the no-EP-escape patch points on first invocation avoids redundant repeated computation.
|
|
For consistency.
|
|
The `too_` prefix wasn't consistently used and just make the
thing longer for no benefit.
|
|
Now that we have 1024B slots, we can store up to 126 fields inline.
Objects larger than this are rare if not non-existent, hence we can
get rid of the `malloc` path for imemo/fields and simply transition
to `TOO_COMPLEX`.
This additionally allows to shrink `attr_index_t` from 16 to 8B.
Note: the ZJIT "ivar on extended" tests are renamed as "complex" because
"extended" AKA malloc allocated imemo/fields no longer exists.
They're now complex fields, AKA st tables.
rb_class_allocate_instance: start as complex when over max_fields
If `RCLASS_MAX_IV_COUNT` is over `max_fields`, allocating a large
slot to end up transitioning to `TOO_COMPLEX` is wasteful.
We might as well start as complex directly.
|
|
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.77.0 to 2.77.1
- [Release notes](https://github.com/taiki-e/install-action/releases)
- [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/taiki-e/install-action/compare/7ea35f098a7369cd23488403f58be9c491a6c55f...cca35edeb1d01366c2843b68fc3ca441446d73d3)
---
updated-dependencies:
- dependency-name: taiki-e/install-action
dependency-version: 2.77.1
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: github-actions
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
|
|
|
|
|
|
|
|
This is how caches used to work prior to 913979bede2a1b79109fa2072352882560d55fe0,
however since inline cache need to be set atomically, they are
limited to 64bits, which wasn't enough to store an `attr_index_t`
and two `shape_id_t`.
But now that we only cache the shape's offset, which is only 19B,
we can store both the source and destination offsets along with
the field index.
Thanks to this, the cache validation is now much simpler, we
only have to do an exact match on the source offset, whereas
before if it wasn't an exact match, we had to try to match
the parent, then check the field name.
We however still have to validate the shape capacity, as
the fast path doesn't handle resizes, but that could be
handled in a followup.
|
|
Given we only store the shape offset in ivar caches, and the
offset is only 19bits, we should be able to store two shape offsets
and an attribute index in a single uint64_t.
Which is perfect for `setivar` caches.
However when initializing caches we set them to `INVALID_SHAPE_ID`
which is a full 32bits.
By making `INVALID_SHAPE_ID` only as large as a shape offset
we open the door to packing more information in ivar caches.
|
|
These are natural variable names, so by using macro like
case we avoid name conflicts.
|
|
To better distinguish fully formed shape ids from "naked" offsets.
|
|
There might have been a reason for this, but it's likely long gone.
|
|
Back when this code was added, moving a T_OBJECT to a different
size pool required to rebuilt its shape tree, which could allocate,
potentially triggering GC during GC.
Ref: https://github.com/ruby/ruby/pull/6926
Ref: https://github.com/ruby/ruby/pull/6938
However, this is no longer a concern.
`SHAPE_T_OBJECT` has been removed, and now transitioning a
shape from one size pool to another never involve an allocation.
Ref: https://github.com/ruby/ruby/pull/13519
Hence we can remove a lot of complexity, and directly update
the shape right after moving the object.
|
|
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.75.30 to 2.77.0
- [Release notes](https://github.com/taiki-e/install-action/releases)
- [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/taiki-e/install-action/compare/db5fb34fa772531a3ece57ca434f579eb334e0fb...7ea35f098a7369cd23488403f58be9c491a6c55f)
---
updated-dependencies:
- dependency-name: taiki-e/install-action
dependency-version: 2.77.0
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: github-actions
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
Verified by wbcheck
|
|
|
|
Since EC is thread-local, we previously used rb_gc_worker_thread_set_vm_context
in MMTk worker threads to temporarily set the EC. However, this was inelegant
and also occasionally caused crashes when marking threads/fibers for the
current EC since it will mark the current machine stack twice (once during
root marking and once for the fiber). However, since the machine
stack is actively being used, the contents may be different when marking
the fiber. Since all objects on the machine stack are pinned, this may
cause an unpinned object to be pinned, which is not allowed in Immix.
The following crash can be observed:
Object 0x200fffbc7d8 is trying to pin 0x200ffc80188
0: mmtk_ruby::handle_gc_thread_panic
1: mmtk_ruby::set_panic_hook::{{closure}}
2: <alloc::boxed::Box<dyn for<'a, 'b> core::ops::function::Fn<(&'a std::panic::PanicHookInfo<'b>,), Output = ()> + core::marker::Sync + core::marker::Send> as core::ops::function::Fn<(&std::panic::PanicHookInfo,)>>::call
at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/alloc/src/boxed.rs:2254:9
3: std::panicking::panic_with_hook
at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/std/src/panicking.rs:833:13
4: std::panicking::panic_handler::{closure#0}
at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/std/src/panicking.rs:698:13
5: std::sys::backtrace::__rust_end_short_backtrace::<std::panicking::panic_handler::{closure#0}, !>
at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/std/src/sys/backtrace.rs:182:18
6: __rustc::rust_begin_unwind
at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/std/src/panicking.rs:689:5
7: core::panicking::panic_fmt
at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/core/src/panicking.rs:80:14
8: <mmtk_ruby::scanning::VMScanning as mmtk::vm::scanning::Scanning<mmtk_ruby::Ruby>>::scan_object_and_trace_edges::{{closure}}
9: mmtk_ruby::abi::ObjectClosure::c_function_registered
10: rb_mmtk_call_object_closure
at gc/mmtk/mmtk.c:976:19
11: rb_gc_impl_mark_and_pin
at gc/mmtk/mmtk.c:1008:5
12: rb_gc_impl_mark_and_pin
at gc/mmtk/mmtk.c:1004:1
13: gc_mark_maybe_internal
at gc.c:2908:5
14: gc_mark_maybe_internal
at gc.c:2906:1
15: gc_mark_maybe_each_location
at gc.c:2939:5
16: gc_mark_maybe_each_location
at gc.c:2937:1
17: each_location
at gc.c:2924:9
18: each_location_ptr
at gc.c:2933:5
19: each_location_ptr
at gc.c:2930:1
20: rb_gc_mark_machine_context
at gc.c:3200:5
21: rb_execution_context_mark
at vm.c:3768:9
22: cont_mark
at cont.c:1155:5
23: fiber_mark
at cont.c:1284:5
24: rb_mmtk_call_gc_mark_children
at gc/mmtk/mmtk.c:318:5
25: <mmtk_ruby::scanning::VMScanning as mmtk::vm::scanning::Scanning<mmtk_ruby::Ruby>>::scan_object_and_trace_edges::{{closure}}
|
|
Stop deriving the embedded-capacity boundary from GC internals in
`upgrade_self_type_to_heap_after_setivar`.
Instead, use self-consistency checks to keep the snapshot only on builds
where five ivars stay embedded and the next write overflows into the
heap-backed self upgrade path.
|
|
The old test snapshot depended on the second write crossing the
embedded-capacity boundary, even though the behavior under test was
just the shape transition across two ivar writes.
Warm the class to two ivars and assert the natural specialized path
instead, so the test covers the intended shape updates without relying
on GC-derived capacity behavior.
|
|
The old setivar opt tests depended on embedded-capacity boundaries that
vary between dev and stats builds.
Compute the boundary from GC::INTERNAL_CONSTANTS and construct receivers
so the tests reliably cover shape transition and heap-backed self
upgrade paths.
|
|
Avoid receiver shapes near the embedded/heap boundary in the
polymorphic getivar tests.
Make both receivers clearly heap-backed so stats and dev builds still
exercise distinct @foo slots without depending on embedded_p().
|
|
|
|
They're the same code.
|
