Daily Bundler CI against ruby-head is failing because ruby-head now
uses bigdecimal 3.1.5, so that gets locked by this spec.
This change should make the test stable until bigdecimal 99.1.5 is
bundled with Ruby :)
https://github.com/rubygems/rubygems/commit/830326041f
We know where it is in the iseq local table, because we forced it using
`iseq_set_exception_local_table` when compiling the BEGIN_NODE, so we
can always look it up from the same place.
Co-Authored-By Peter Zhu <peter@peterzhu.ca>
Instead of storing the delegate in @tmpfile, use __getobj__, since
delegate library already handles dup/clone for that. Copy the
unlinked, mode, and opts instance variables to the returned object
when using dup/clone.
Split the close/unlink finalizer into two finalizers. The close
finalizer always closes when any Tempfile instance is GCed, since
each Tempfile instance uses a separate file descriptor. The unlink
finalizer unlinks only when the original and all duped/cloned
Tempfiles are GCed, since all share the same path.
For Tempfile#open, undefine the close finalizer after closing the
current file, the redefine the close finalizer with the new file.
Fixes [Bug #19441]
https://github.com/ruby/tempfile/commit/dafabf9c7b
before this change, creating a regex from a regex with a named capture, Regexp.new(/(?<name>)/), causes memory to be shared between the two named capture groups which can cause a segfault if the original is GCed.
Since #6945 the extension dir changed to Gem::BasicSpecification's implementation, we didn't hook that in rubygems_ext.rb. So for universal rubies, we ended up using the universal platform name when installing, but arch replaced platform name when checking. This lead to native extensions can never be correctly installed on universal rubies.
Hook Gem::BasicSpecifications so the behavior is consistent on installing and checking.
https://github.com/rubygems/rubygems/commit/8d699ed096
Right now the `rb_shape_get_next` shape caller need to
first check if there is capacity left, and if not call
`rb_shape_transition_shape_capa` before it can call `rb_shape_get_next`.
And on each of these it needs to checks if we got a TOO_COMPLEX
back.
All this logic is duplicated in the interpreter, YJIT and RJIT.
Instead we can have `rb_shape_get_next` do the capacity transition
when needed. The caller can compare the old and new shapes capacity
to know if resizing is needed. It also can check for TOO_COMPLEX
only once.
(https://github.com/ruby/irb/pull/708)
* Add completor using prism and rbs
* Add TypeCompletion test
* Switchable completors: RegexpCompletor and TypeCompletion::Completor
* Add completion info to irb_info
* Complete reserved words
* Fix [*] (*) {**} and prism's change of KeywordParameterNode
* Fix require, frozen_string_literal
* Drop prism<=0.16.0 support
* Add Completor.last_completion_error for debug report
* Retrieve `self` and `Module.nesting` in more safe way
* Support BasicObject
* Handle lvar and ivar get exception correctly
* Skip ivar reference test of non-self object in ruby < 3.2
* BaseScope to RootScope, move method objects constant under Methods
* Remove unused Splat struct
* Drop deeply nested array/hash type calculation from actual object. Now, calculation depth is 1
* Refactor loading rbs in test, change preload_in_thread not to cache Thread object
* Use new option added in prism 0.17.1 to parse code with localvars
* Add Prism version check and warn when :type completor cannot be enabled
* build_type_completor should skip truffleruby (because endless method definition is not supported)
https://github.com/ruby/irb/commit/1048c7ed7a
Comparing file paths as strings may not work well for some reasons,
symlink, relative `__FILE__`, etc.
Some alternatives are possible: comparing with `File.realpath`, or
with `File.identical?`, it should be most robust to escape the target
string contained within this file itself.
Instead, don't check that at all and proceed. If something fails to be
written inside GEM_HOME, we'll eventually fail with a proper permissions
error.
In addition to that, the writable bit in GEM_HOME is not even reliable,
because only the immediate parent is actually checked when writing. For
example,
```
$ mkdir -p foo/bar
$ chmod -w foo
$ touch foo/bar/baz # writes without issue
```
https://github.com/rubygems/rubygems/commit/4bced7ac73
The combination of `install-dir` and `--user-install` used to be
disabled for no good reason. This even makes problem on Linux
distributions such as Fedora, where `--user-install` is set by default
via operating_system.rb.
The `--install-dir` is already prefered over the `--user-install` by
the implementation, therefore just drop the check.
https://github.com/rubygems/rubygems/commit/313b1c5e76
It is not nice to require install directory to be always specified,
while this option is later ignored for user installed gems.
Actually, the next step will be to remove `check_install_dir` check and
let the install dir override the user install.
https://github.com/rubygems/rubygems/commit/beb79e929f
The main purpose is to put handling of user installation into the same
place as e.g. handling the --build-root option handling. There is no
reason why the --build-root option should not prefix also paths used for
user installation.
Please note that the `util_installer` in
`test_generate_plugins_with_user_install` enforced the `:install_dir`,
which is against what user install is about.
https://github.com/rubygems/rubygems/commit/0b10cb41aa