[pull] master from ruby:master #492
Merged
Conversation
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
Fixes Shopify#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.
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. ruby/rubygems@68c39c8451
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.
- ### 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. ruby/rubygems@f0ef526f23
- 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. ruby/rubygems@380653ae74
- 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
ruby/rubygems@e716adb6c9
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.
before_exec stops the timer thread, which requires locking the Ractor scheduler lock. This may deadlock if rb_gc_before_fork locks the VM.
…efinition is used
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. ruby/rubygems@2896aa3fc2 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`. ruby/rubygems@6c94623881 Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>
This specifies the lockfile location. This allows for easy support of different lockfiles per Ruby version or platform. ruby/rubygems@b54d65bc0a Co-authored-by: Sutou Kouhei <kou@cozmixng.org> Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>
This was a test case for Ractors discovered that causes MMTk to deadlock. There is a fix for it in ruby/mmtk#49.
clang-18 has a bug that causes the latest Ractor btest to crash.
…15264) - 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.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
12 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 : )