If a gem is specified in the Gemfile (or resolved as a transitive
dependency), it's always resolved from remote/installed sources. Default
gems are only used as a fallback for gems not included in the bundle.
I believe this leads to more consistent behavior and more portable apps,
since all gems will be installed to the configured bundle path,
regardless of whether they are default gems or not.
https://github.com/rubygems/rubygems/commit/091b4fcf2b
This makes bundler consistent with all other gems, and makes the default
installation of Bundler in the release package look like any other
bundler installation.
Before (on preview3, for example), Bundler executable is installed at:
lib/ruby/gems/3.3.0+0/gems/bundler-2.5.0.dev/libexec/bundle
Now it's installed in the standard location:
lib/ruby/gems/3.3.0+0/gems/bundler-2.5.0.dev/exe/bundle
This is mainly to align this test case with the
`test_process_options_does_not_fallback_to_user_install_when_gem_home_
not_writable_and_no_user_install`, where the `install_dir` is checked
already.
https://github.com/rubygems/rubygems/commit/02b1884b61
The `options[:user_install]` might have three states:
* `true`: `--user-install`
* `false`: `--no-user-install` and
* `nil`: option was not specified
However, this had not been respected previously and the `false` and `nil`
were treated the same. This could lead to auto user installation despite
`--no-user-install` being specified on the command line.
Fixes https://github.com/rubygems/rubygems/pull/7237https://github.com/rubygems/rubygems/commit/9281545474
This commit passes an `end` to rb_int_parse_cstr which allows us
to correctly parse non-base 10 integers which are enclosed in
parenthesis. Prior to this commit, we were getting a putobject nil
when compiling `(0o0)` for example.
With the latest version of the postponed job patchset merged, we don't
actually need to go through the contortions of keeping the data in a
global variable; we can just update `data` with multiple calls to
rb_postponed_job_preregister.
The previous implementation of hash deopt was based on clearing the static literal flag on a hash node if the element that was being added was an array, hash or range node, or if the element was not a static literal in the first place.
However, this is not correct. First of all, the elements added to a hash node will primarily be assoc nodes, but never array, hash or range nodes. Secondly, the static literal flag is set on assoc nodes, only if the value in an assoc node is a static literal, so the key is never checked. As a result, the static literal flag on a hash node would never be cleared if the key wasn't a static literal.
This commit fixes this by clearing the static literal flag if:
1. the element is not an assoc node,
2. the element is an assoc node, but the key is not a static literal, or
3. the element is an assoc node, the key is a static literal, but assoc node (and thus the value in assoc node) is not a static literal.
https://github.com/ruby/prism/commit/7f67109b36
Previously, if the method ID argument happens to be on one below the top
of the stack, we didn't overwrite the type of the stack slot, which
leaves an incorrect type for the stack slot. The included script tripped
asserts both with and without --yjit-verify-ctx.
When you have an interpolated regex with a `once` flag and local
variable is outside the block created by the `once` flag, Prism would
see a segv. This is because it was not taking the depth into account.
To fix this, we need to add 1 to the `local_depth_offset` on the
`scope`.
Fixes: ruby/prism#2047
This was first added in b481b673d75, but 197e91f357 added
-DUNIVERSAL_PARSER to the Compilers workflow as well.
Given the nature of this test and the fact that it also runs make
test-all besides make test, I think it's better to keep only the
Compilers one.
ForwardingSuperNodes need to actually forward any applicable
arguments. This commit implements that logic, by using the data
stored on the local iseq about the parameters to forward the
appropriate arguments.
