| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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]
|
|
As can be seen in vm_block_handler_verify(), VM_BLOCK_HANDLER_NONE is
not a valid argument for vm_block_handler(). Store nil in the profiler
when seen instead of crashing.
|
|
|
|
## Components
This PR adds functionality to visualize HIR using the [Iongraph](https://spidermonkey.dev/blog/2025/10/28/iongraph-web.html) tool first created for use with Spidermonkey.
## Justification
Iongraph's viewer is (as mentioned in the article above) a few notches above graphviz for viewing large CFGs. It also allows easily inspecting different compiler optimization passes and multiple functions in the same browser window. Since Spidermonkey is using this format, it may be beneficial to use it for our own JIT development.
The requirement for JSON is downstream from that of the Iongraph format. As for writing the implementation myself, ZJIT leans towards having fewer dependencies, so this is the preferred approach.
## How does it look?
<img width="902" height="957" alt="image" src="https://github.com/user-attachments/assets/e4e0991b-572a-41fd-9fed-1215bd1926c3" />
<img width="770" height="624" alt="image" src="https://github.com/user-attachments/assets/01398373-1f75-46b8-b1aa-7f5d4cbca6b8" />
Right now, it's aesthetically minimal, but is fairly robust.
## Functionality
Using `--zjit-dump-hir-iongraph` will dump all compiled functions into a directory named `/tmp/zjit-iongraph-{PROCESS_PID}`. Each file will be named `func_{ZJIT_FUNC_NAME}.json`. In order to use them in the Iongraph viewer, you'll need to use `jq` to collate them to a single file. An example invocation of `jq` is shown below for reference. The name of the file created does not matter to my understanding.
`jq --slurp --null-input '.functions=inputs | .version=2' /tmp/zjit-iongraph-{PROCESS_PID}/func*.json > ~/Downloads/foo.json`
From there, you can use https://mozilla-spidermonkey.github.io/iongraph/ to view your trace.
### Caveats
- The upstream Iongraph viewer doesn't allow you to click arguments to an instruction to find the instruction that they originate from when using the format that this PR generates. (I have made a small fork at https://github.com/aidenfoxivey/iongraph that fixes that functionality via https://github.com/aidenfoxivey/iongraph/commit/9e9c29b41c4dbb35cf66cb6161e5b19c8b796379.patch)
- The upstream Iongraph viewer can sometimes show "exiting edges" in the CFG as being not attached to the box representing its basic block.
<img width="1814" height="762" alt="image" src="https://github.com/user-attachments/assets/afbbaa16-332f-498f-849e-11c69a8cb0cc" />
(Image courtesy of @tekknolagi)
This is because the original tool was (to our understanding) written for an SSA format that does not use extended basic blocks. (Extended basic blocks let you put a jump instruction, conditional or otherwise, anywhere in the basic block.) This means that our format may generate more outgoing edges than the viewer is written to handle.
|
|
|
