[pull] master from ruby:master #687
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
…5871) Make sure we check if we have seen a singleton for this class before assuming we have not. Port the API from YJIT.
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
cpush_all() and cpop_all() in theory enabled these `print_*` utilities to work in more spots, but with automatically spilling in asm.ccall(), the benefits are now limited. They also have a bug at the moment. Stop using them to dodge the bug.
Previously, cpop_all() did not in fact restore the register mapping state since it was effectively doing a no-op `self.ctx.set_reg_mapping(self.ctx.get_reg_mapping())`. This desync in bookkeeping led to issues with the --yjit-dump-insns option because print_str() used to use cpush_all() and cpop_all().
Or else we put garbage into the flags.
* ZJIT: Profile `invokesuper` instructions * ZJIT: Introduce the `InvokeSuperDirect` HIR instruction The new instruction is an optimized version of `InvokeSuper` when we know the `super` target is an ISEQ. * ZJIT: Expand definition of unspecializable to more complex cases * ZJIT: Ensure `invokesuper` optimization works when the inheritance hierarchy is modified * ZJIT: Simplify `invokesuper` specialization to most common case Looking at ruby-bench, most `super` calls don't pass a block, which means we can use the already optimized `SendWithoutBlockDirect`. * ZJIT: Track `super` method entries directly to avoid GC issues Because the method entry isn't typed as a `VALUE`, we set up barriers on its `VALUE` fields. But, that was insufficient as the method entry itself could be collected in certain cases, resulting in dangling objects. Now we track the method entry as a `VALUE` and can more naturally mark it and its children. * ZJIT: Optimize `super` calls with simple argument forms * ZJIT: Report the reason why we can't optimize an `invokesuper` instance * ZJIT: Revise send fallback reasons for `super` calls * ZJIT: Assert `super` calls are `FCALL` and don't need visibily checks
It was introduced as part of the Arm64-on-Windows patch: #8995 But a few days later it was fixed on the LLVM side for llvm-18 and backported to MSYS2: msys2/MINGW-packages#19157 (comment) Now this code is only unnecessary complexity.
The previous example code was too complex and includes extra logics that's not relevant to its main usage: `bind`. The new example code focuses on `bind_call` so that readers can understand how it works more easily.
…vate()
This patch fixes a problem where `binding.irb` (= force_activate('irb'))
fails under `bundle exec` when the Gemfile does not contain `irb` and
does contain a gem which is (1) not installed in GEM_HOME (2) sourced
using `path:`/`git:`.
The original approach constructing a temporary definition fails since
it does not set the equalivent of `path:`/`git:`.
Always reconstructing a definition from a Gemfile and applying lockfile
constraints should be a more robust approach.
[Bug #21723]
Bundler::Runtime#setup requires a real existing lockfile (see Bundler::SharedHelpers#default_lockfile).
This patch silences the "this won't work in the next version of Ruby"
warning displayed when irb is autoloaded via `binding.irb`.
main.rb:1: warning: irb used to be loaded from the standard library, but is not part of the default gems since Ruby 4.0.0.
You can add irb to your Gemfile or gemspec to fix this error.
/.../irb.rb:9: warning: reline used to be loaded from the standard library, but is not part of the default gems since Ruby 4.0.0.
You can add reline to your Gemfile or gemspec to fix this error.
From: main.rb @ line 1 :
=> 1: binding.irb
/.../input-method.rb:284: warning: rdoc used to be loaded from the standard library, but is not part of the default gems since Ruby 4.0.0.
You can add rdoc to your Gemfile or gemspec to fix this error.
This warning is incorrect and misleading: users should not need to
include irb (and its dependencies) to their Gemfiles to use
`binding.irb`, even in future versions of Ruby. It is agreed that the
runtime takes care of that.
Users should add `irb` to their Gemfile. `Gem::BUNDLED_GEMS.force_activate 'irb'` is workaround for short term.
Only when YJIT is enabled, the redefinition of `Array#<<` affects these methods.
… make use of it later (e.g. fold_constants for ArrayAref)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
11 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 : )