| Age | Commit message (Collapse) | Author |
|---|
|
`SEPARATOR_LIST` is used only to initialize `SEPARATOR_PAT`.
|
|
After 607648d5fc9 (`bundle config get` exits 1 when the value is unset),
the spec added in 4658d6bd78b raises in the bundle helper because the
new test invokes `config get gemfile` after unsetting it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
When using something like `bundle config set foo false`, the config value is converted via `Bundler::Settings#converted_value`, so the stored value becomes `false` instead of the string `"false"`. Because of that, passing `Bundler.settings[name]` directly to an `if` statement can execute `exit 1` even when the value is actually configured.
Since config values do not appear to become `nil` explicitly, use `nil?` to determine whether the value is configured.
https://github.com/ruby/rubygems/commit/8fd32cb611
|
|
Refactor the code based on the feedback in https://github.com/ruby/rubygems/pull/9505#discussion_r3167085736 .
https://github.com/ruby/rubygems/commit/153abcb5e3
|
|
not set
Fix https://github.com/ruby/rubygems/pull/3215
Change the exit status to 1 when trying to `get` a config key that does not exist, as shown below.
```sh
$ bundle config get foo
Settings for `foo` in order of priority. The top value will be used
You have not configured a value for `foo`
$ echo $?
1
```
It seems that showing “Settings for `foo` in order of priority. The top value will be used” when the key does not exist is not very meaningful, but for now I have left the behavior unchanged except for the exit status.
In the tests, some existing cases try to `get` a missing config without `raise_on_error: false`, so set the value in advance or add `raise_on_error: false` to handle them.
https://github.com/ruby/rubygems/commit/73205e3d64
|
|
complete_platform validates platform-specific candidates returned by
spec.source.specs.search, which are remote specs that do not carry
the override list. Borrow the override list from the LazySpec exemplar
already in scope so platform-variant validation uses the same effective
metadata as the install/resolve path.
Also propagate the overrides onto the synthesized LazySpec built from
platform_spec. Without this, the next complete_platform call could
pick the synthesized variant as its exemplar (it is now in the set
returned by lookup) and fall back to strict matching, dropping
platforms that the user's override would otherwise allow.
https://github.com/ruby/rubygems/commit/205955c5b3
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
SpecSet previously kept its own @overrides and a with_overrides setter
that had to be chained on every SpecSet.new(...) site (~13 sites in
Definition alone). Two Codex review rounds both flagged forgotten
chains in different SpecSet construction paths, which is exactly the
class of bug the chain pattern invites: it is purely "remember to
write" with no compiler help.
Move the override list to LazySpecification#overrides instead. The
LazySpec is the natural carrier — it is the value object the resolver
and install paths already pass around, and choose_compatible already
read overrides off it. Override.attach(specs, overrides) is added as
the dual of Override.find_for so Definition (after lockfile load) and
Resolver (after solve_versions) can populate the overrides on every
LazySpec they hand out, and LazySpecification.from_spec carries the
list forward when one LazySpec spawns another. Generic spec types
(StubSpecification, plain Gem::Specification, RemoteSpecification)
are intentionally ignored so generic metadata callers (SelfManager,
materialize-time strict checks) keep their current strict semantics.
SpecSet drops attr_accessor :overrides, the @overrides initialisation,
the with_overrides cascade, and reverts SpecSet#valid? to the strict
matches_current_metadata? check. Every SpecSet.new(...) site in
Definition stops chaining .with_overrides — the LazySpecs already
carry the context.
https://github.com/ruby/rubygems/commit/fc1e8d4d7e
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
overrides
SpecSet#with_overrides cascaded into each contained spec via
`respond_to?(:overrides=)`. RemoteSpecification#respond_to? forwards
to _remote_specification, which materializes the backing gemspec just
to answer the predicate. spec/runtime/require_spec.rb verifies that
Bundler does not load gemspecs it does not need by deliberately
poisoning one with `raise 'broken gemspec'`; the cascade tripped that
guard and made `Bundler.setup` blow up.
Gate the cascade on `is_a?(LazySpecification)` instead. Only
LazySpecification declares `attr_accessor :overrides` (used by
`#choose_compatible`), so the predicate is equivalent for any spec we
ever set overrides on, and it never triggers the lazy gemspec load.
https://github.com/ruby/rubygems/commit/2a1e7d5c23
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
SpecSet#incomplete_specs_for_platform constructed a fresh
self.class.new(@specs) for platform validation but never copied
@overrides. Platform-validity decisions therefore evaluated strict
required_ruby_version / required_rubygems_version metadata even when
resolution was running with overrides, so a metadata override could
allow a gem everywhere except platform validation, where the platform
might be marked incomplete and pruned.
Carry @overrides forward via with_overrides on the cloned SpecSet.
https://github.com/ruby/rubygems/commit/11b7c58a5a
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Definition#resolve falls back to an existing lockfile when nothing
about the Gemfile or the locked deps changed. The two SpecSet rebuild
paths (deleted_deps subset and the redundant-platform-specific-gems
fallback) constructed fresh SpecSet instances without carrying
@overrides forward, so any LazySpec produced from them lost its
override context. After Step G that mattered: an :all metadata
override does not pre-unlock anything by design, which means it must
flow through these reuse paths intact.
Without it, the materialize layer either silently re-resolved (which
churns the lockfile) or, on the install-time check, fell back to the
spec's strict required_ruby_version metadata. Calling with_overrides
on both rebuilt SpecSets keeps the install-time behavior consistent
across resolve and lockfile-reuse paths.
https://github.com/ruby/rubygems/commit/81fb91a8b1
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Previously, any :all override called unlock_all_locked_specs_for_override
which pushed every locked spec into @gems_to_unlock. A user adding a
narrow `override :all, required_ruby_version: :ignore_upper` thus paid
for a full re-resolve that could pull unrelated dependency
upgrades/downgrades.
Make :all overrides leave the lockfile alone at converge time. They
take effect on a fresh resolution (no lockfile) or when the user opts
in via `bundle update`. Per-gem overrides retain their unlock for the
named gem since the user explicitly named the target.
https://github.com/ruby/rubygems/commit/3c95ab99e3
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Phase 2.C wired overrides into MatchMetadata via Bundler.overrides, a
process-wide accessor read every time a spec answered
matches_current_metadata?. That leaked the user's Gemfile overrides
into Bundler-internal callers like SelfManager#remote_specs, where
overrides have no business: a Gemfile override could let bundle
self-update consider Bundler releases that are actually incompatible
with the running Ruby/RubyGems.
Revert MatchMetadata's matches_current_ruby? and matches_current_rubygems?
to evaluate the spec's own metadata, and add explicit
matches_current_*_with_overrides? variants. Pass overrides explicitly:
Installer#ensure_specs_are_compatible! gets them from @definition,
LazySpecification#choose_compatible reads its newly-added @overrides
attribute, and SpecSet#valid? reads @overrides set on the SpecSet.
Definition propagates @overrides to the SpecSets it constructs and to
the LazySpecs they contain. SelfManager and other callers that should
keep evaluating real gemspec metadata reach the strict path
unchanged.
https://github.com/ruby/rubygems/commit/e0ff753bbb
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Update the OVERRIDE section to cover the :all target, the
required_ruby_version / required_rubygems_version fields, and the
diagnostic shown on resolve failure.
https://github.com/ruby/rubygems/commit/ac90c83b1b
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Append the list of currently active overrides (with Gemfile location,
when known) to the SolveFailure message so a user investigating a
"could not find compatible versions" error sees what override changed
the constraint set instead of being misled by the resolver-reported
requirement.
https://github.com/ruby/rubygems/commit/10b8b53270
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Bundler::Dsl#override now records caller_locations(1, 1).first on
each Override so the originating Gemfile line can be surfaced in
later diagnostics.
https://github.com/ruby/rubygems/commit/ef73385cdc
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Drive bundle install end-to-end with a gem whose required_ruby_version
or required_rubygems_version excludes the current runtime, asserting
that a per-gem override (and an :all override) makes the install
succeed instead of erroring at the install-time compatibility gate.
https://github.com/ruby/rubygems/commit/dbc9f24269
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
matches_current_ruby? / matches_current_rubygems? now look up the
current Definition's overrides via Bundler.overrides and apply them
before checking against the runtime Ruby/RubyGems version. This
covers Installer#ensure_specs_are_compatible! and the materialize-
layer choose_compatible / SpecSet#valid? checks uniformly without
plumbing overrides through every materialization site.
When no Definition is set yet (e.g. RubyGems-side calls outside a
Bundler.definition block), Bundler.overrides returns an empty list
and the methods fall through to their original behavior.
https://github.com/ruby/rubygems/commit/afe9313b6e
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Exercise :all required_ruby_version overrides applied to multiple gems
at once, the per-gem precedence rule, and re-resolution against an
existing lockfile when an :all override is introduced.
https://github.com/ruby/rubygems/commit/81f2bfcf9b
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
An :all override applies to every gem's metadata, so we have no way to
know which locked entries it affects without re-resolving. Force-unlock
them all when an :all override appears so the resolver gets a fresh
chance to apply the override.
https://github.com/ruby/rubygems/commit/4f61f6813e
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Override.find_for now returns the per-gem entry when present and
otherwise the matching :all entry on the same field. This is the
single dispatch point for overrides in Definition and Resolver, so
the fallback is what wires :all into resolution and lockfile change
detection without further plumbing.
https://github.com/ruby/rubygems/commit/ef24b4eef9
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Remove the temporary "not yet supported" guard so a Gemfile may write
`override :all, required_ruby_version: :ignore_upper` and similar
forms. The version: ban for :all stays — version requirements are
inherently per-gem.
https://github.com/ruby/rubygems/commit/af09f0360a
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
overrides
Add integration coverage exercising :ignore_upper and nil overrides
against per-gem metadata fields, transitive propagation, and lockfile
re-resolution when a metadata override is added against an existing
lockfile. The cases drive `bundle lock` so they exercise the resolver
without RubyGems' install-time required_ruby_version gate, which is
addressed in a later step.
https://github.com/ruby/rubygems/commit/ec3a549df7
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
The per-dep loop in converge_dependencies only knows about version:
overrides via apply_override_to + matches_spec?. Metadata overrides
on direct deps were therefore invisible to lockfile change detection
and would silently no-op against an existing lock. Extend
converge_overrides_outside_dependencies to also unlock direct deps
when the override targets a non-version field.
https://github.com/ruby/rubygems/commit/fdd4c30523
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
When a spec's runtime dependencies are gathered for the resolver, its
required_ruby_version / required_rubygems_version metadata flow as
synthetic Ruby\0 / RubyGems\0 dependencies. Rewrite those before
they reach the dependency hash so per-gem overrides on those fields
take effect during resolution.
https://github.com/ruby/rubygems/commit/853e00f778
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
overrides
Extend the override DSL whitelist so per-gem metadata fields can be
declared. The :all target is rejected for now with a "not yet
supported" error so the field is purely per-gem until the next step
adds :all propagation.
https://github.com/ruby/rubygems/commit/f9e4d7bf29
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Lock the byroot policy decision (overrides are a Gemfile concept and
must not be serialized into Gemfile.lock) with a regression test, so a
future change that starts emitting override metadata in the lock would
fail loudly.
https://github.com/ruby/rubygems/commit/9524b785c5
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Before this change, `override "rails", version: "not a version"` was
accepted by Bundler::Dsl#override and only failed later when the
resolver tried to instantiate Gem::Requirement. Surface the error at
the Gemfile evaluation step so the user sees it on the offending line.
https://github.com/ruby/rubygems/commit/2ae83fbb4f
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Definition#apply_override_to, Definition#converge_dependencies, and
Resolver#apply_overrides each duplicated the same find expression.
Centralizing it on Override prepares for upcoming fields (and the :all
target) without repeating the predicate in every call site.
https://github.com/ruby/rubygems/commit/0c4424d5f3
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Add the recent developer meeting, we discussed switching from using
pessimistic versioning by default to using optimistic versioning by
default. This is the a step in that direction. It makes bundle add
without a explicit version given to use >= (optimistic) instead of
~> (pessimistic).
With this, the bundle add --optimistic option is now ignored, since
the behavior is now the default. This add a --pessimistic option to
set a pessimistic version.
https://github.com/ruby/rubygems/commit/eed378086b
|
|
|
|
To the code where they are actually initialized.
|
|
https://github.com/ruby/rubygems/commit/38f87aa2bc
|
|
|
|
and $@)
Ruby::Box fix stale cached values for exception-related global variables ($! and $@)
The exception-related virtual variables $! (current exception) and
$@ (its backtrace) are stored on the execution context (ec->errinfo
and the rescue/ensure frame's local slot accessed via errinfo_place),
not in box->gvar_tbl. Caching their values in box->gvar_tbl makes the
second read return a stale value from the previous raise/rescue:
```
begin; raise "first"; rescue; p $!; end
begin; raise "second"; rescue; p $!; end
# before: #<RuntimeError: first> / #<RuntimeError: first>
# after: #<RuntimeError: first> / #<RuntimeError: second>
```
```
begin; raise "first"; rescue; p $@.first; end
begin; raise "second"; rescue; p $@.first; end
# before: same backtrace returned for both
# after: distinct backtrace per raise
```
Fixes [Bug #21991](https://bugs.ruby-lang.org/issues/21991)
Related PR: https://github.com/ruby/ruby/pull/16303
|
|
|
|
|
|
This would allow rb_gc_event_hook to run in a GC thread that is a
non-Ruby thread.
|
|
The ripper translator is a good resource when porting ripper usage over to prism
A few places use `visit_token` when it can be more specific.
A call operator for example can ever only be one of three things.
A positional argument can only ever be a identifier (no constant, no global, etc.)
Also removes some stale comments. There are `*_TargetNode` for these now.
https://github.com/ruby/prism/commit/62511d59a2
|
|
Previously, we kept around `PatchPoint`s after patching them for several
kinds of invariants. That wasted compute since repeated invalidation
with the same key patched a growing list of patchpoints each time,
making it accidentally O(n^2). Retaining the patchpoints also used memory.
Some invariants, such as rb_zjit_invalidate_no_singleton_class() and
rb_zjit_invalidate_root_box(), already remove from the table. This commit
makes all invariants remove from the table.
|
|
`Pathname::SEPARATOR_PAT` should be private, but was not set to
private just due to a typo.
https://github.com/ruby/rubygems/commit/67ce6df4c9
|
|
The first sub-test froze on the 6th comparator call. CRuby's insertion sort makes 10 comparisons reversing [1,2,3,4,5], but TimSort detects the descending run in 4 and never reaches 6 and the freeze line silently does nothing.
Separately, three independent paths (block + numeric, block + non-numeric, no-block + non-numeric) were bundled into one method even though the test had independent setup. Split into:
test_freeze_inside_sort_bang
test_freeze_inside_sort_bang_non_numeric_block
test_freeze_inside_sort_bang_non_numeric_no_block
|
|
In glob_opendir(), each directory entry is copied before the entries
array is grown. If growing ent->sort.entries fails, the function jumps
to the nomem label before the copied entry is stored in the array.
glob_dir_finish() only frees entries already recorded in
ent->sort.entries, so the current rdp is leaked on that error path.
Free rdp before jumping to nomem.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
|
|
- AC_ARG_ENABLE's action-if-given ran unconditionally for both
--enable-multiarch and --disable-multiarch, setting multiarch=""
in both cases
- ${multiarch+set} treats an empty-string variable as set, so
--disable-multiarch was silently ignored and multiarch stayed enabled
- Use AS_CASE([$enableval], ...) to unset multiarch when "no" is given
|
|
|
|
converge_dependencies only iterates @dependencies (Gemfile-declared
direct deps), so an override that targets a gem present only as a
transitive dependency never registered as a change. With an existing
lockfile, @dependency_changes stayed false, the resolver was skipped,
and the override was a silent no-op. After the direct-dep loop,
inspect @overrides for any String target that is locked but not a
direct dep and force it onto @gems_to_unlock / @changed_dependencies
so resolution runs and the Resolver-side override hook applies.
https://github.com/ruby/rubygems/commit/a4f8f386f2
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Add an OVERRIDE section between GEMSPEC and SOURCE PRIORITY that
covers the syntax, the three operations (version spec string,
:ignore_upper, nil), and the lockfile-vs-resolution boundary.
https://github.com/ruby/rubygems/commit/275cbcaef3
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Verify end-to-end that override(..., version: nil) collapses the
requirement to Gem::Requirement.default for both direct deps (a
Gemfile pin to 0.9.1 is removed) and transitive deps (a
myrack_middleware-imposed = 0.9.1 floor is removed).
https://github.com/ruby/rubygems/commit/7df463f5c7
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
Verify end-to-end that override(..., version: :ignore_upper) drops
< / <= bounds and folds ~> into >= so a Gemfile-pinned 0.9.1 ceiling
no longer prevents myrack 1.0.0 from being chosen.
https://github.com/ruby/rubygems/commit/95224cff50
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
When the Gemfile dependency does not request a prerelease,
Resolver::Package's prerelease policy normally filters them out.
Because Definition#expanded_dependencies now feeds the effective
(override-applied) dep into Resolver::Base, an override that pins an
exact prerelease propagates into the package's prerelease decision
and the prerelease becomes selectable. Lock that contract in with an
integration test on a has_prerelease 1.0 / 1.1.pre fixture.
https://github.com/ruby/rubygems/commit/a40b224354
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
converge_dependencies compared the original Gemfile dependency
against the locked spec, so adding `override "foo", version: "= X"`
to a previously installed bundle did not register as a change.
additional_base_requirements_to_prevent_downgrades then kept
forwarding the locked version as a >= base requirement, which
intersected the override and made it a no-op. Pass overrides into
Definition.new positionally so they are available before the
constructor calls converge_dependencies, and compare each direct
dep's effective requirement (after override) to the locked spec.
https://github.com/ruby/rubygems/commit/248e1ba385
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
