* Fix Array#[] with ArithmeticSequence with negative steps
Previously, Array#[] when called with an ArithmeticSequence
with a negative step did not handle all cases correctly,
especially cases involving infinite ranges, inverted ranges,
and/or exclusive ends.
Fixes [Bug #18247]
* Add Array#slice tests for ArithmeticSequence with negative step to test_array
Add tests of rb_arithmetic_sequence_beg_len_step C-API function.
* Fix ext/-test-/arith_seq/beg_len_step/depend
* Rename local variables
* Fix a variable name
Co-authored-by: Kenta Murata <3959+mrkn@users.noreply.github.com>
Adding `ruby` to `PREP` causes the following circular dependencies
because `PREP` is used as a prerequisite by some targets required to
build `ruby` target itself.
```
make: Circular .rbconfig.time <- ruby dependency dropped.
make: Circular builtin_binary.inc <- ruby dependency dropped.
make: Circular ext/extinit.c <- ruby dependency dropped.
make: Circular ruby <- ruby dependency dropped.
```
Adding a new Make variable like `EXTPREP` only for exts may be also
reasonable, but it would introduce another complexity into our build
system. `-bundle_loader` doesn't care that link-time and run-time
loader executables are different as long as bound symbols are provided,
so it's ok to resolve from miniruby to simplify our build.
For the macOS -bundle_loader linker option, we need a path to the
Ruby exectuable. $(RUBY) is not necessarily a path since it could
be a command line invocation. That happens during build with
runruby.rb and can happen post installation if the user passes
the --ruby option to a extconf.rb. Use $(bindir) to locate
the executable instead.
Before installation, $(bindir) doesn't exist, so we need to be
able to override $(BUILTRUBY) in such situations so test-spec
and bundled extensions could build. Use a new mkmf global,
$builtruby, to do this; set it in fake.rb and in extmk.rb.
Our build system is quite complex...
ld64 shipped with Xcode 14 emits a warning when using `-undefined
dynamic_lookup`.
```
ld: warning: -undefined dynamic_lookup may not work with chained fixups
```
Actually, `-undefined dynamic_lookup` doesn't work when:
1. Link a *shared library* with the option
2. Link it with a program that uses the chained-fixup introduced from
macOS 12 and iOS 15
because `-undefined dynamic_lookup` uses lazy-bindings and they won't be
bound while dyld fixes-up by traversing chained-fixup info.
However, we build exts as *bundles* and they are loaded only through
`dlopen`, so it's safe to use `-undefined dynamic_lookup` in theory.
So the warning produced by ld64 is false-positive, and it results
failure of option checking in configuration. Therefore, it would be an
option to ignore the warning during our configuration.
On the other hand, `-undefined dynamic_lookup` is already deprecated on
all darwin platforms except for macOS, so it's good time to get rid of
the option. ld64 also provides `-bundle_loader <executable>` option,
which allows to resolve symbols defined in the executable symtab while
linking. It behaves almost the same with `-undefined dynamic_lookup`,
but it makes the following changes:
1. Require that unresolved symbols among input objects must be defined
in the executable.
2. Lazy symbol binding will lookup only the symtab of the bundle loader
executable. (`-undefined dynamic_lookup` lookups all symtab as flat
namespace)
This patch adds `-bundle_loader $(RUBY)` when non-EXTSTATIC
configuration by assuming ruby executable can be linked before building
exts.
See "New Features" subsection under "Linking" section for chained fixup
https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes
Treats:
::httpdate
#to_date
#to_time
#to_datetime
In behalf of ::httpdate, I've introduced section "Argument limit" that can be pointed to by various Date methods (similar to existing section "Argument start"). This will involve 8 already-enhanced methods plus 8 more not yet done.
https://github.com/ruby/date/commit/00326ff99c
Tabs were expanded because the file did not have any tab indentation in unedited lines.
Please update your editor config, and use misc/expand_tabs.rb in the pre-commit hook.
Tabs were expanded because the file did not have any tab indentation in unedited lines.
Please update your editor config, and use misc/expand_tabs.rb in the pre-commit hook.
It makes testing for JSON errors very tedious. You either have
to use a Regexp or to regularly update all your assertions
when JSON is upgraded.
https://github.com/flori/json/commit/de9eb1d28e
rb_ary_tmp_new suggests that the array is temporary in some way, but
that's not true, it just creates an array that's hidden and not on the
transient heap. This commit renames it to rb_ary_hidden_new.
The `rb_profile_frames` API did not skip the two dummy frames that
each thread has at its beginning. This was unlike `backtrace_each` and
`rb_ec_parcial_backtrace_object`, which do skip them.
This does not seem to be a problem for non-main thread frames,
because both `VM_FRAME_RUBYFRAME_P(cfp)` and
`rb_vm_frame_method_entry(cfp)` are NULL for them.
BUT, on the main thread `VM_FRAME_RUBYFRAME_P(cfp)` was true
and thus the dummy thread was still included in the output of
`rb_profile_frames`.
I've now made `rb_profile_frames` skip this extra frame (like
`backtrace_each` and friends), as well as add a test that asserts
the size and contents of `rb_profile_frames`.
Fixes [Bug #18907] (<https://bugs.ruby-lang.org/issues/18907>)
Sidekiq has a method named `❨╯°□°❩╯︵┻━┻`which corrupts
heap dumps.
Normally we could just dump is as is since it's valid UTF-8 and need
no escaping. But our code to escape control characters isn't UTF-8
aware so it's more complicated than it seems.
Ultimately since the overwhelming majority of method names are
pure ASCII, it's not a big loss to just skip it.
When configuring with `--disable-rpath` and `--static-linked-ext` (e.g.
building for WASI), `extmk.rb` doesn't build exts under bundled gems,
and `.bundle/gems/#{gemname}-#{ver}` are not created due to no call of
`extmake`.
b249178398 starts creating symlink at
`.bundle/gems/#{gemname}-#{ver}/lib`, but the parent dir is not created,
so configuration aginst debug and rbs gems were failed.
The default gems have not been installed yet in the build directory,
bundled gems depending on them can not work. As those dependencies
should be usable there even without rubygems, make temporary gemspec
files without the dependencies, and use them in the build directory.
Brings a dozen call-seq schemas into compliance with the doc guide.
Adds links to section "Argument start" where needed.
Revises (minorly) ::today.
Otherwise, does not disturb existing text.
https://github.com/ruby/date/commit/9aec11df50
On Windows with OpenSSL 3, the gem fails to compile with the following
error message:
ruby/src/ext/openssl/extconf.rb:188: undefined method \`sub!' for nil:NilClass
This is because $warnflags is nil.
[Bug #18900]
Thread#join and a few other codepaths are using native sleep as
a way to suspend the current thread. So we should call the relevant
hook when this happen, otherwise some thread may transition
directly from `RESUMED` to `READY`.
I suspect that some shared pages are invalidated because
some static string don't have their coderange set eagerly.
So the first time they are scanned, the entire memory page is
invalidated.
Being able to see the coderange in `ObjectSpace` would help debug
this.
And in addition `dump` currently call `is_broken_string()` and `is_ascii_string()`
which both end up scanning the string and assigning coderange. I think it's
undesirable as `dump` should be read only.
[Feature #18339]
After experimenting with the initial version of the API I figured there is a need
for an exit event to cleanup instrumentation data. e.g. if you record data in a
{thread_id -> data} table, you need to free associated data when a thread goes away.
I tried to build Ruby on a system without libyaml today and realized
that my attempt from <https://github.com/ruby/psych/pull/557> doesn't
fix the error in <https://github.com/ruby/psych/issues/552>. I still got
the same `LoadError` from `digest` which stopped the build.
Since `LoadError` is not a `StandardError`, a plain `rescue` doesn't catch
it. Catch `LoadError` explicitly instead and reduce the scope of the
`begin` block.
I tested this change in a Ruby build on macOS without libyaml installed
and confirmed that `make` continues with a warning instead of aborting:
*** Following extensions are not compiled:
psych:
Could not be configured. It will not be installed.
...
This should address <https://bugs.ruby-lang.org/issues/18790>.
https://github.com/ruby/psych/commit/251289ba83
Previously, because opt_aref and opt_aset don't push a frame, when they
would call rb_hash to determine the hash value of the key, the initial
level of recursion would incorrectly use the method id at the top of the
stack instead of "hash".
This commit replaces rb_exec_recursive_outer with
rb_exec_recursive_outer_mid, which takes an explicit method id, so that
we can make the hash calculation behave consistently.
rb_exec_recursive_outer was documented as being internal, so I believe
this should be okay to change.
Ref: https://bugs.ruby-lang.org/issues/18339
Design:
- This tries to minimize the overhead when no hook is registered.
It should only incur an extra unsynchronized boolean check.
- The hook list is protected with a read-write lock as to cause
contention when some hooks are registered.
- The hooks MUST be thread safe, and MUST NOT call into Ruby as they
are executed outside the GVL.
- It's simply a noop on Windows.
API:
```
rb_internal_thread_event_hook_t * rb_internal_thread_add_event_hook(rb_internal_thread_event_callback callback, rb_event_flag_t internal_event, void *user_data);
bool rb_internal_thread_remove_event_hook(rb_internal_thread_event_hook_t * hook);
```
You can subscribe to 3 events:
- READY: called right before attempting to acquire the GVL
- RESUMED: called right after successfully acquiring the GVL
- SUSPENDED: called right after releasing the GVL.
The hooks MUST be threadsafe, as they are executed outside of the GVL, they also MUST NOT call any Ruby API.
Try to mirror IO behavior, where chomp takes out the entire paragraph
separators between entries, but does not chomp a single line separator
at the end of the string.
Partially Fixes [Bug #18768]
https://github.com/ruby/stringio/commit/a83ddbb7f0
Previously, this could result in an infinite loop. Always update
the e pointer in this case, setting w when chomping so the chomped
data is not included in the output.
Fixes [Bug #18769]
https://github.com/ruby/stringio/commit/4bf64d5130
In December 2021, we opened an [issue] to solicit feedback regarding the
porting of the YJIT codebase from C99 to Rust. There were some
reservations, but this project was given the go ahead by Ruby core
developers and Matz. Since then, we have successfully completed the port
of YJIT to Rust.
The new Rust version of YJIT has reached parity with the C version, in
that it passes all the CRuby tests, is able to run all of the YJIT
benchmarks, and performs similarly to the C version (because it works
the same way and largely generates the same machine code). We've even
incorporated some design improvements, such as a more fine-grained
constant invalidation mechanism which we expect will make a big
difference in Ruby on Rails applications.
Because we want to be careful, YJIT is guarded behind a configure
option:
```shell
./configure --enable-yjit # Build YJIT in release mode
./configure --enable-yjit=dev # Build YJIT in dev/debug mode
```
By default, YJIT does not get compiled and cargo/rustc is not required.
If YJIT is built in dev mode, then `cargo` is used to fetch development
dependencies, but when building in release, `cargo` is not required,
only `rustc`. At the moment YJIT requires Rust 1.60.0 or newer.
The YJIT command-line options remain mostly unchanged, and more details
about the build process are documented in `doc/yjit/yjit.md`.
The CI tests have been updated and do not take any more resources than
before.
The development history of the Rust port is available at the following
commit for interested parties:
1fd9573d8b
Our hope is that Rust YJIT will be compiled and included as a part of
system packages and compiled binaries of the Ruby 3.2 release. We do not
anticipate any major problems as Rust is well supported on every
platform which YJIT supports, but to make sure that this process works
smoothly, we would like to reach out to those who take care of building
systems packages before the 3.2 release is shipped and resolve any
issues that may come up.
[issue]: https://bugs.ruby-lang.org/issues/18481
Co-authored-by: Maxime Chevalier-Boisvert <maximechevalierb@gmail.com>
Co-authored-by: Noah Gibbs <the.codefolio.guy@gmail.com>
Co-authored-by: Kevin Newton <kddnewton@gmail.com>
WHen libyaml is not installed, make fails with the following cryptic
message:
```
gmake[2]: Entering directory '/home/chkbuild/chkbuild-crossruby/tmp/build/20220325T045825Z/ruby/ext/psych'
gmake[2]: *** No rule to make target 'yaml/yaml.h', needed by 'psych.o'. Stop.
gmake[2]: Leaving directory '/home/chkbuild/chkbuild-crossruby/tmp/build/20220325T045825Z/ruby/ext/psych'
```
I think it should give up building psych with a clear message.
Header file include/ruby/internal/abi.h contains RUBY_ABI_VERSION which
is the ABI version. This value should be bumped whenever an ABI
incompatible change is introduced.
When loading dynamic libraries, Ruby will compare its own
`ruby_abi_version` and the `ruby_abi_version` of the loaded library. If
these two values don't match it will raise a `LoadError`. This feature
can also be turned off by setting the environment variable
`RUBY_RUBY_ABI_CHECK=0`.
This feature will prevent cases where previously installed native gems
fail in unexpected ways due to incompatibility of changes in header
files. This will force the developer to recompile their gems to use the
same header files as the built Ruby.
In Ruby, the ABI version is exposed through
`RbConfig::CONFIG["ruby_abi_version"]`.
Inside ObjectSpace.reachable_objects_from we keep an internal identhash
in order to de-duplicate reachable objects when wrapping them as
InternalObject. Previously this hash was not hidden, making it possible
to leak references to those internal objects to Ruby if using
ObjectSpace.each_object.
This commit solves this by hiding the hash. To simplify collection of
values, we instead now just use the hash as a set of visited objects,
and collect an Array (not hidden) of values to be returned.
The gem doesn't even install on old rubies, but since the gemspec claims
it's supported, `gem install pathname` will try to install it and print
an error.
This commit doesn't fix the above issue. The only way to fix it would be
to restore support and release a new version that actually supports old
rubies. However, such a change has been proposed and ignored for a long
time.
So this issue proposes to leave that broken but at least bring the
gemspec manifest and the CI matrix in sync to hopefully avoid this issue
from happening again in the future.
https://github.com/ruby/pathname/commit/3ee010b538
It does not seem needed, and it's causing issues on Windows when
uninstalling `strscan`, because strscan's shared library being used when
RubyGems tries to remove it (because its loaded through Psych, which
RubyGems uses for loading configuration).
https://github.com/ruby/psych/commit/3911356ec1
* Enhanced RDoc for BigDecimal
* Update ext/bigdecimal/bigdecimal.c
Remove the instance number of `Float::DIG`.
* Update ext/bigdecimal/bigdecimal.c
Add BigDecimal call-seq without ndigits.
* Update ext/bigdecimal/bigdecimal.c
Replace the word sum with value or result in the description of BigDecimal().
* Update ext/bigdecimal/bigdecimal.c
Remove the instance value of Float::DIG.
* Update ext/bigdecimal/bigdecimal.c
Fix mis-description of precision
* Update ext/bigdecimal/bigdecimal.c
Fix the description of precision determination
* Update ext/bigdecimal/bigdecimal.c
Add the description of the precision in the Rational case.
https://github.com/ruby/bigdecimal/commit/acabb132a4
Co-authored-by: Kenta Murata <3959+mrkn@users.noreply.github.com>
OpenSSL 3.0's EVP_PKEY_get0() returns NULL for provider-backed pkeys.
This causes segfault because it was supposed to never return NULL
before.
We can't check the existence of public key components in this way on
OpenSSL 3.0. Let's just skip it for now.
https://github.com/ruby/openssl/commit/ccdb6f7bfa
The entire ENGINE API is deprecated in OpenSSL 3.0 in favor of the new
"Provider" concept.
OpenSSL::Engine will not be defined when compiled with OpenSSL 3.0.
We would need a way to interact with providers from Ruby programs, but
since the concept is completely different from the ENGINE API, it will
not be through the current OpenSSL::Engine interface.
https://github.com/ruby/openssl/commit/69a27d8de4
OpenSSL 3.0 made EVP_PKEY immutable. This means we can only have a const
pointer of the low level struct and the following methods can no longer
be provided when linked against OpenSSL 3.0:
- OpenSSL::PKey::RSA#set_key
- OpenSSL::PKey::RSA#set_factors
- OpenSSL::PKey::RSA#set_crt_params
- OpenSSL::PKey::DSA#set_pqg
- OpenSSL::PKey::DSA#set_key
- OpenSSL::PKey::DH#set_pqg
- OpenSSL::PKey::DH#set_key
- OpenSSL::PKey::EC#group=
- OpenSSL::PKey::EC#private_key=
- OpenSSL::PKey::EC#public_key=
There is no direct replacement for this functionality at the moment.
I plan to introduce a wrapper around EVP_PKEY_fromdata(), which takes
all key components at once to construct an EVP_PKEY.
https://github.com/ruby/openssl/commit/6848d2d969
OpenSSL::PKey::EC#generate_key! will not work on OpenSSL 3.0 because
keys are made immutable. Users should use OpenSSL::PKey.generate_key
instead.
https://github.com/ruby/openssl/commit/5e2e66cce8
OpenSSL::PKey::DH#generate_key! will not work on OpenSSL 3.0 because
keys are made immutable. Users should use OpenSSL::PKey.generate_key
instead.
https://github.com/ruby/openssl/commit/8ee6a582c7
DH#set_key will not work on OpenSSL 3.0 because keys are immutable.
For now, let's reimplement DH#compute_key by manually constructing a
DER-encoded SubjectPublicKeyInfo structure and feeding it to
OpenSSL::PKey.read.
Eventually, we should implement a new method around EVP_PKEY_fromdata()
and use it instead.
https://github.com/ruby/openssl/commit/46ca47060c
Allocate an EVP_PKEY when the content is ready: when #initialize
or #initialize_copy is called, rather than when a T_DATA is allocated.
This is more natural because the lower level API has been deprecated
and an EVP_PKEY is becoming the minimum unit of handling keys.
https://github.com/ruby/openssl/commit/74f6c61756
OpenSSL 3.0 has rewritten routines to load pkeys (PEM_read_bio_* and
d2i_* functions) around the newly introduced OSSL_DECODER API.
This comes with a slight behavior change. They now decrypt and parse
each encountered PEM block, then check the kind of the block. This used
to be the reverse: they checked the PEM header to see the kind, and then
decrypted the content. This means that the password callback may now be
called repeatedly.
Let's use the OSSL_DECODER API directly on OpenSSL 3.0 so that the
return value from the password callback will be reused automatically.
https://github.com/ruby/openssl/commit/a84ea531bb
This `NODE` type was used in pre-YARV implementation, to improve
the performance of assignment to dynamic local variable defined at
the innermost scope. It has no longer any actual difference with
`NODE_DASGN`, except for the node dump.
Jeremy Evans
Alexander Momchilov
Nobuyoshi Nakada
Burdette Lamar
Yuta Saito
Alan Wu
Thomas Winsnes
Koichi Sasada
git
Hiroshi SHIBATA
Jean Boussier
Peter Zhu
Ivo Anjo
Jean byroot Boussier
Takashi Kokubun
Karl Anderson
Jarek Prokop
twkmd12
Stefan Kaes
Samuel Williams
John Hawthorn
Florian Frank
Andrew Bromwich
MSP-Greg
Sutou Kouhei
Alan Wu
Kazuhiro NISHIYAMA
Tanaka Akira
Akinori MUSHA
Stan Lo
Yusuke Endoh
xtkoba
Charles Oliver Nutter
Mau Magnaguagno
Matt Valentine-House
David Rodríguez
apatniv
Kenta Murata
Seth Boyles
Michael Nikitochkin
David CARLIER
NARUSE, Yui
Kazuki Yamaguchi
Olle Jonsson