Currently our tests try to detect whether `cargo` is installed or not,
and if not, set tests that need `cargo` as pending.
However, when this happens that test `setup` method is completely
skipped, meaning that the `teardown` method will blow up when trying to
switch back to the original folder, since it was not set.
This commit fixes that.
1e4c1e6492
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>
Not sure if this is the correct fix. It does raise LocalJumpError in
the yielding thread as you would expect, but the value yielded to the calling
thread is still yielded without an exception.
Fixes [Bug #18649]
The ignore_eof setting on HTTPResponse makes it so an EOFError is
raised when reading bodies with a defined Content-Length, if the
body read was truncated due to the socket be closed.
The ignore_eof setting on HTTP sets the values used in responses
that are created by the object.
For backwards compatibility, the default is for both settings is
true. However, unless you are specifically tested for and handling
truncated responses, it's a good idea to set ignore_eof to false so
that errors are raised for truncated responses, instead of those
errors silently being ignored.
Fixes [Bug #14972]
4d47e34995
Previously in some when classes were duped (specifically those with a
prepended module), they would not correctly have their "superclasses"
array or depth filled in.
This could cause ancestry checks (like is_a? and Module comparisons) to
return incorrect results.
This happened because rb_mod_init_copy builds origin classes in an order
that doesn't have the super linked list fully connected until it's
finished. This commit fixes the previous issue by calling
rb_class_update_superclasses before returning the cloned class. This is
similar to what's already done in make_metaclass.
We were trying to remove directories using `FileUtils.rm_f` which is
unexpected and does not remove anything. Changing to `FileUtils.rm_rf`
actually removes the directories properly. That itself showed other
issues:
* One test was actually removing the gem package it was about to
install, since it was living in the cache folder. To fix that, avoid
removing the cache folder, and only make sure the other directories
are created automatically, which seems enough.
* Another test was actually removing an incorrect directory. Change it
to remove the right one (the one that's asserted later to have been
created).
5538e7ff20
Previously, the content-encoding header was removed and the body
was modified, but the content-length header was not modified,
resulting in the content-length header not matching the body
length.
Don't delete content-length before yielding inflate body, as that
causes a switch to read the entire body instead of reading in
chunks.
Fixes [Bug #16672]
58284e9710
Co-authored-by: st0012 <stan001212@gmail.com>
Only valid characters for URLs should be used for generating URLs.
A list of valid characters can be found in sections 2.2 and 2.3 of IETF
RFC 3986 (https://www.ietf.org/rfc/rfc3986.txt).
2bd8fcdd4f
Allocating a string of length MAXPATHLEN and then shrinking the string
is inefficient when the resulting path is short. Preallocating a large
string is also a problem for Variable Width Allocation since we can't
easily downsize the capacity.
I ran the following benchmark:
```ruby
Benchmark.ips do |x|
{
"empty" => "",
"short" => "a/" * 10,
"medium" => "a/" * 100,
"long" => "a/" * 500
}.each do |name, path|
x.report(name) do |times|
i = 0
while i < times
File.expand_path(path)
i += 1
end
end
end
end
```
On this commit:
```
empty 97.486k (± 0.7%) i/s - 492.915k in 5.056507s
short 96.026k (± 2.4%) i/s - 486.489k in 5.068966s
medium 86.304k (± 1.3%) i/s - 435.336k in 5.045112s
long 59.395k (± 1.7%) i/s - 302.175k in 5.089026s
```
On master:
```
empty 94.138k (± 1.4%) i/s - 472.158k in 5.016590s
short 92.043k (± 1.4%) i/s - 468.180k in 5.087496s
medium 84.910k (± 2.3%) i/s - 425.750k in 5.017007s
long 61.503k (± 2.7%) i/s - 309.723k in 5.039429s
```
This allows for the ability to opt-in to a method to set the
encoding of response bodies. By setting the accessor to a String
or Encoding instance, it will use the specified encoding.
Setting the value of true will try to detect the encoding of the
response body, either using the Content-Type header (assuming it
specifies charset) or by scanning for a <meta> tag in the document
that specifies the encoding. The default is false in which case
no forcing of encoding will be done (same as before the patch).
Implements [Feature #2567]
Implements [Feature #15517]
6233e6b7c1
Co-authored-by: Yui Naruse <naruse@ruby-lang.org>
Check whether the current or previous frame is a Ruby frame in
call_trace_func and rb_tracearg_binding before attempting to
create a binding for the frame.
Fixes [Bug #18487]
Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>
We have seen some errors during test `setup` before `@tempdir` is
actually set, in particular, when instantiating `Gem::MockUI` which in
turn requires `stringio`. In this case, the `teardown` method will also
produce an error because it tries to remove the `@tempdir`, which has
not been set, so tries to remove a `nil` directory. It results in a
confusing error like
```
<internal:D:/a/rubygems/rubygems/lib/rubygems/core_ext/kernel_require.rb>:85:in `require': Interrupt
Error: test_bump_one_level(TestGemVersion): TypeError: no implicit conversion of nil into String
C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/3.1.0/fileutils.rb:1570:in `path'
from <internal:D:/a/rubygems/rubygems/lib/rubygems/core_ext/kernel_require.rb>:85:in `require'
C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/3.1.0/fileutils.rb:1570:in `block in fu_list'
from D:/a/rubygems/rubygems/lib/rubygems/mock_gem_ui.rb:43:in `initialize'
C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/3.1.0/fileutils.rb:1570:in `map'
from D:/a/rubygems/rubygems/test/rubygems/helper.rb:323:in `new'
C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/3.1.0/fileutils.rb:1570:in `fu_list'
from D:/a/rubygems/rubygems/test/rubygems/helper.rb:323:in `setup'
C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/3.1.0/fileutils.rb:616:in `rm_r'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/fixture.rb:284:in `run_fixture_callback'
C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/3.1.0/fileutils.rb:638:in `rm_rf'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/fixture.rb:272:in `block in create_fixtures_runner'
D:/a/rubygems/rubygems/test/rubygems/helper.rb:462:in `teardown'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/fixture.rb:276:in `block in create_fixtures_runner'
===============================================================================
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/fixture.rb:257:in `run_fixture'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/fixture.rb:292:in `run_setup'
Finished in 683.0312862 seconds.
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/testcase.rb:564:in `block in run'
-------------------------------------------------------------------------------
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/testcase.rb:563:in `catch'
2185 tests, 5929 assertions, 0 failures, 1 errors, 28 pendings, 0 omissions, 0 notifications
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/testcase.rb:563:in `run'
98.7185% passed
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/testsuite.rb:124:in `run_test'
-------------------------------------------------------------------------------
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/testsuite.rb:53:in `run'
3.20 tests/s, 8.68 assertions/sTerminate batch job (Y/N)?
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/testsuite.rb:124:in `run_test'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/testsuite.rb:53:in `run'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/testsuite.rb:124:in `run_test'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/testsuite.rb:53:in `run'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/ui/testrunnermediator.rb:67:in `run_suite'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/ui/testrunnermediator.rb:45:in `block (2 levels) in run'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/ui/testrunnermediator.rb:102:in `with_listener'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/ui/testrunnermediator.rb:41:in `block in run'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/ui/testrunnermediator.rb:39:in `catch'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/ui/testrunnermediator.rb:39:in `run'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/ui/testrunner.rb:40:in `start_mediator'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/ui/testrunner.rb:25:in `start'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/ui/testrunnerutilities.rb:24:in `run'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/autorunner.rb:458:in `block in run'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/autorunner.rb:514:in `change_work_directory'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/autorunner.rb:457:in `run'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit/autorunner.rb:66:in `run'
from C:/hostedtoolcache/windows/Ruby/3.1.1/x64/lib/ruby/gems/3.1.0/gems/test-unit-3.5.3/lib/test/unit.rb:518:in `block (2 levels) in <top (required)>'
rake aborted!
Interrupt:
```
The should make this same error much cleaner if it happens again.
fa649d22e8
For a method such as:
def foo(*callee_args) end
If this method is called with a flagged hash (created by a method
flagged with ruby2_keywords), this previously passed the hash
through without modification. With this change, it acts as if the
last hash was passed as keywords, so a call to:
foo(*caller_args)
where the last element of caller_args is a flagged hash, will be
treated as:
foo(*caller_args[0...-1], **caller_args[-1])
As a result, inside foo, callee_args[-1] is an unflagged duplicate
of caller_args[-1] (all other elements of callee_args match
caller_args).
Fixes [Bug #18625]
This commit reintroduces finer-grained constant cache invalidation.
After 8008fb7 got merged, it was causing issues on token-threaded
builds (such as on Windows).
The issue was that when you're iterating through instruction sequences
and using the translator functions to get back the instruction structs,
you're either using `rb_vm_insn_null_translator` or
`rb_vm_insn_addr2insn2` depending if it's a direct-threading build.
`rb_vm_insn_addr2insn2` does some normalization to always return to
you the non-trace version of whatever instruction you're looking at.
`rb_vm_insn_null_translator` does not do that normalization.
This means that when you're looping through the instructions if you're
trying to do an opcode comparison, it can change depending on the type
of threading that you're using. This can be very confusing. So, this
commit creates a new translator function
`rb_vm_insn_normalizing_translator` to always return the non-trace
version so that opcode comparisons don't have to worry about different
configurations.
[Feature #18589]
