| Age | Commit message (Collapse) | Author |
|---|
|
Comparing version objects is a huge bottleneck in dependency solvers
(like inside Bundler). I would like to make comparing version objects
cheaper. Right now we support comparing version objects with strings by
trying to coerce the string to a version. So for example:
```ruby
Gem::Version.new("1") <=> "12"
```
I would like to deprecate and remove support for this feature so that we
can reduce the overhead of `def <=>`.
I'm not sure what version of RubyGems we could remove this from though.
https://github.com/ruby/rubygems/commit/81b7602183
|
|
https://github.com/ruby/rubygems/commit/c1e3d4d63b
|
|
```
Offenses:
Rakefile:18:1: C: [Correctable] Layout/EmptyLines: Extra blank line detected.
Diff:
@@ -11,4 +11,5 @@
ext.lib_dir = "lib/test_gem"
end
+
task default: :compile
https://github.com/ruby/rubygems/commit/8c414729df
|
|
https://github.com/ruby/rubygems/commit/64f92d2da0
|
|
|
|
|
|
Going through a call to a C function just to read a bitfield was a
little extreme. We did it to be super conservative since bitfields
have historically been the trigger of many bugs and surprises. Let's
try directly accessing them with code from rust-bindgen. If this
ends up causing issues, we can use the FFI approach behind nicer
wrappers.
In any case, directly access regular struct fields such as `lead_num`
and `opt_num` to remove boilerplate.
|
|
This will make reading the parameters nicer for the JITs. Should be
no-op for the C side.
|
|
- Buffer's size did not account for offset when mapping the file, leading to possible crashes.
- Size and offset were not checked properly, leading to many situations raising EINVAL errors with generic messages.
- Documentation was wrong.
|
|
https://github.com/ruby/rubygems/commit/f360af8e3b
|
|
clang-18 has a bug that causes the latest Ractor btest to crash.
|
|
This was a test case for Ractors discovered that causes MMTk to deadlock.
There is a fix for it in https://github.com/ruby/mmtk/pull/49.
|
|
This specifies the lockfile location. This allows for easy support
of different lockfiles per Ruby version or platform.
https://github.com/ruby/rubygems/commit/b54d65bc0a
Co-authored-by: Sutou Kouhei <kou@cozmixng.org>
Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>
|
|
This allows for the same behavior as including `lockfile false`
in the Gemfile. This allows you to get the behavior without
modifying the Gemfile, which is useful if you do not control the
Gemfile.
This is similar to the --no-lock option already supported by
`gem install -g Gemfile`.
https://github.com/ruby/rubygems/commit/6c94623881
Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>
|
|
This allows you to specify the lockfile to use. This is useful if
you want to use different lockfiles for different ruby versions or
platforms. You can also skip writing the lockfile by using a false
value.
https://github.com/ruby/rubygems/commit/2896aa3fc2
Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>
|
|
definition is used
|
|
|
|
|
|
|
|
|
|
|
|
before_exec stops the timer thread, which requires locking the Ractor
scheduler lock. This may deadlock if rb_gc_before_fork locks the VM.
|
|
|
|
|
|
|
|
Previously this held a pointer to the Fiber itself, which requires
marking it (which was only implemented recently, prior to that it was
buggy). Using a monotonically increasing integer instead allows us to
avoid having a free function and keeps everything simpler.
My main motivations in making this change are that the root fiber lazily
allocates self, which makes the writebarrier implementation challenging
to do correctly, and wanting to avoid sending Mutexes to the remembered
set when locked by a short-lived Fiber.
|
|
|
|
- With the logger change that is now threadsafe, such code no longer
behaves the same:
```ruby
Bundler.ui.silence do
Bundler.ui.level = 'info'
Bundler.ui.info("foo")
# This used to output something. Now it doesn't.
end
```
IMHO this is the right behaviour since we are in a silence block,
changing the level should have no effect. And fortunately it seems
that we only need to change this spec.
The call to `Bundler.ui.silence` is done in a `around` block
https://github.com/ruby/rubygems/blob/4a13684f07ebb1dea5501e3f826fab414f96bf47/bundler/spec/spec_helper.rb#L119
https://github.com/ruby/rubygems/commit/e716adb6c9
|
|
- The Logger is not thread safe when calling `with_level`.
This now becomes problematic because we are using multiple
threads during the resolution phase in order to fetch git gems.
https://github.com/ruby/rubygems/commit/380653ae74
|
|
- ### Problem
When you have a Gemfile that contains git gems, each repository will
be fetched one by one. This is extremelly slow.
A simple Gemfile with 5 git gems (small repositories) can take up
to 10 seconds just to fetch the repos.
We can speed this up by running multiple git process and fetching
repositories silmutaneously.
### Solution
The repositories are fetched in Bundler when `Source::Git#specs` is
called.
The problem is that `source.specs` is called in various places
depending on Gemfile.
I think the issue is that calling `source.specs` feels like that
as a "side effect" we are going to clone repositories. I believe
that fetching repositories should be an explicit call.
For instance:
```ruby
source "https://rubygems.org"
gem "foo", github: "foo/foo"
# The repository foo will be fetched as a side effect to the call to `source.spec_names`
# https://github.com/ruby/rubygems/blob/6cc7d71dac3d0275c9727cf200c7acfbf6c78d37/bundler/lib/bundler/source_map.rb#L21
```
```ruby
source "https://rubygems.org"
gem "bar", source: "https://example.org"
gem "foo", github: "foo/foo"
# The repository foo will be fetched on a different codepath
# https://github.com/ruby/rubygems/blob/6cc7d71dac3d0275c9727cf200c7acfbf6c78d37/bundler/lib/bundler/source/rubygems_aggregate.rb#L35
# That is because the gem "bar" has a source that doesn't have the `/dependencies` API
# endpoint and therefore Bundler enters a different branch condition.
```
I opted to add a self explanatory call to fetch the git source
repositories just before we start the resolution, and *just*
before any other calls to `source.specs` is performed.
https://github.com/ruby/rubygems/commit/f0ef526f23
|
|
Found by wbcheck
It seems like here the classext was associated with the class, but it
already had Ruby objects attached.
rb_gc_writebarrier_remember works around that issue, but I suspect if we
enabled autocompaction the values copied into the classext before it was
attached could be broken.
|
|
|
|
|
|
This is a first pass to improve the way errors are handled and raised in
bundler's tests. The goal is to clean up tests and modernize them -
these were some obvious areas that could be cleaned up.
- Instead of raising "ZOMG" in the load error tests, it now tests for
the actual error and gem raising.
- Improve error messages where applicable.
- All errors raise a specific error class, rather than falling back to a
default and just setting a message.
- Removed arguments and `bundle_dir` option from `TheBundle` class as it wasn't
actually used so therefore we don't need to raise an error for extra
arguments.
- Removed error from `BundlerBuilder`, as it won't work if it's not
`bundler`, also it never uses `name`. The only reaon `name` is passed
in is because of metaprogramming on loading the right builder. I
think that should eventually be refactored.
- Replaced and removed `update_repo3` and `update_repo4` in favor of
just `build_repo3` and `build_repo4`. Rather than tell someone writing
tests to use a different method, automatically use the right method.
https://github.com/ruby/rubygems/commit/68c39c8451
|
|
related to #2667
https://github.com/ruby/prism/commit/44f075bae4
|
|
Fixes https://github.com/ruby/prism/pull/3736.
https://github.com/ruby/prism/commit/1f5f192ab7
|
|
Fixes https://github.com/Shopify/ruby/issues/877
I didn't consider the ability to have the successor or predecessor sets having duplicates when originally crafting the Iongraph support PR, but have added this to prevent that happening in the future.
I don't think it interferes with the underlying Iongraph implementation, but it doesn't really make sense.
I think this kind of behaviour happens when there are multiple jump instructions that go to the same basic block within a given block.
|
|
https://github.com/ruby/json/commit/9364d0c761
|
|
|
|
|
|
For subclasses from Set, require `set/subclass_compatible`, and
extend the subclass and include a module in it that makes it more
backwards compatible with the pure Ruby Set implementation used
before Ruby 4.
The module included in the subclass contains a near-copy of the
previous Set implementation, with the following changes:
* Accesses to `@hash` are generally replaced with `super` calls. In
some cases, they are replaced with a call to another instance method.
* Some methods that only accessed `@hash` and nothing else are not
defined, so they inherit behavior from core Set.
* The previous `Set#divide` implementation is not used, to avoid
depending on tsort.
This fixes the following two issues:
* [Bug #21375] Set[] does not call #initialize
* [Bug #21396] Set#initialize should call Set#add on items passed in
It should also fix the vast majority of backwards compatibility issues
in other cases where code subclassed Set and depended on implementation
details (such as which methods call which other methods).
This does not affect Set internals, so Set itself remains fast. For
users who want to subclass Set but do not need to worry about
backwards compatibility, they can subclass from Set::CoreSet, a Set
subclass that does not have the backward compatibility layer included.
|
|
`rb_zjit_option_enabled_p` seems no longer used/defined since
ruby/ruby#f84bbb423836d9d0d018b8ab71ecceb5868fd5be.
|
|
`realloc` is not guaranteed to return the same address when shrinking.
|
|
Now win32/registry depends on fiddle, and its conversion is complex
and too generic for the purpose of resolv.
https://github.com/ruby/resolv/commit/bd24870d2d
|
|
|
|
https://github.com/ruby/rubygems/commit/9be811c01a
|
|
This test has been reliably failing on recent trunk versions.
See: <https://github.com/ruby/ruby/actions/runs/19519712433/job/55880266450#step:14:120>
|
|
[Feature #20408]
|
|
[Feature #20408]
|
|
[Feature #20408]
|
