Cfuncs that use rb_scan_args with the : entry suffer similar keyword
argument separation issues that Ruby methods suffer if the cfuncs
accept optional or variable arguments.
This makes the following changes to : handling.
* Treats as **kw, prompting keyword argument separation warnings
if called with a positional hash.
* Do not look for an option hash if empty keywords are provided.
For backwards compatibility, treat an empty keyword splat as a empty
mandatory positional hash argument, but emit a a warning, as this
behavior will be removed in Ruby 3. The argument number check
needs to be moved lower so it can correctly handle an empty
positional argument being added.
* If the last argument is nil and it is necessary to treat it as an option
hash in order to make sure all arguments are processed, continue to
treat the last argument as the option hash. Emit a warning in this case,
as this behavior will be removed in Ruby 3.
* If splitting the keyword hash into two hashes, issue a warning, as we
will not be splitting hashes in Ruby 3.
* If the keyword argument is required to fill a mandatory positional
argument, continue to do so, but emit a warning as this behavior will
be going away in Ruby 3.
* If keyword arguments are provided and the last argument is not a hash,
that indicates something wrong. This can happen if a cfunc is calling
rb_scan_args multiple times, and providing arguments that were not
passed to it from Ruby. Callers need to switch to the new
rb_scan_args_kw function, which allows passing of whether keywords
were provided.
This commit fixes all warnings caused by the changes above.
It switches some function calls to *_kw versions with appropriate
kw_splat flags. If delegating arguments, RB_PASS_CALLED_KEYWORDS
is used. If creating new arguments, RB_PASS_KEYWORDS is used if
the last argument is a hash to be treated as keywords.
In open_key_args in io.c, use rb_scan_args_kw.
In this case, the arguments provided come from another C
function, not Ruby. The last argument may or may not be a hash,
so we can't set keyword argument mode. However, if it is a
hash, we don't want to warn when treating it as keywords.
In Ruby files, make sure to appropriately use keyword splats
or literal keywords when calling Cfuncs that now issue keyword
argument separation warnings through rb_scan_args. Also, make
sure not to pass nil in place of an option hash.
Work around Kernel#warn warnings due to problems in the Rubygems
override of the method. There is an open pull request to fix
these issues in Rubygems, but part of the Rubygems tests for
their override fail on ruby-head due to rb_scan_args not
recognizing empty keyword splats, which this commit fixes.
Implementation wise, adding rb_scan_args_kw is kind of a pain,
because rb_scan_args takes a variable number of arguments.
In order to not duplicate all the code, the function internals need
to be split into two functions taking a va_list, and to avoid passing
in a ton of arguments, a single struct argument is used to handle
the variables previously local to the function.
`rb_bug()` is called at critical bug, MRI can't run anymore.
To make debug easy, this patch introduces RUBY_ON_BUG environment
variable to specify the process which is called with pid.
[Feature #16090] [GH #2331]
RUBY_ON_BUG='gdb -p' ruby xxx.rb
In this case, if ruby interpreter causes critical bug, and call
rb_bug(), then "gdb -p [PID]' is called by system(3). You can
debug on invoked gdb.
This feature is limited on RUBY_DEVEL build.
Exception#backtrace and Exception#backtrace_locations can both be nil if
not set. The former can be set via `Exception#set_backtrace`, but the
later is only ever set at runtime via `setup_backtrace`.
You can rescue it:
f = ObjectSpace.each_object(Class){|c| break c if c.name == 'fatal'}
begin
raise f
rescue f
2
end # => 2
It's not a good idea to rescue fatal exceptions you didn't generate
yourself, though.
Fixes [Bug #10691]
FrozenError#receiver was added recently for getting the related
object programmatically. However, there are cases where FrozenError
is raised and not handled, and in those cases the resulting error
messages lack detail, which makes debugging the error more difficult,
especially in cases where the error is not easily reproducible.
This includes the inspect value of the frozen object in FrozenError
messages, which should make debugging simpler.
Similar to NameError#receiver, this returns the object on which
the modification was attempted. This is useful as it can pinpoint
exactly what is frozen. In many cases when a FrozenError is
raised, you cannot determine from the context which object is
frozen that you attempted to modify.
Users of the current rb_error_frozen C function will have to switch
to using rb_error_frozen_object or the new rb_frozen_error_raise
in order to set the receiver of the FrozenError.
To allow the receiver to be set from Ruby, support an optional
second argument to FrozenError#initialize.
Implements [Feature #15751]
This message is showed on SEGV, but it is usually caused by 3rd party
libraries and we don't help reporters well. I concluded this message
doesn't help users as expected.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67061 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* eval_error.c (print_errinfo): defer escaping control char in
error messages until writing to stderr, instead of quoting at
building the message. [ruby-core:90853] [Bug #15497]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66753 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Especially over checking argc then calling rb_scan_args just to
raise an ArgumentError.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66238 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Warning.warn does not add any newlines to the message argument.
[Bug #15379]
From: Olle Jonsson <olle.jonsson@gmail.com>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66208 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Similar to rb_typeddata_is_kind_of, except for that inherited type
is not an instance.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66019 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The former states explicitly that the argument must be a literal,
and can optimize away `strlen` on all compilers.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65059 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The symbol that can be used is `:bottom`, not `:down`.
Ref: e39b2cff8a/error.c (L1061)
[Fix GH-1916]
From: yuuji.yaginuma <yuuji.yaginuma@gmail.com>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63984 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* It causes SEGV on `warn("foo", uplevel: 100)`.
* Found in a ruby/spec added by @andrykonchin in
https://github.com/ruby/spec/pull/605
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63650 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* error.c (rb_get_backtrace): check the result of `backtrace` even
if the method is redefined. [ruby-core:87013] [Bug #14756]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63417 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* error.c (name_err_init_attr): hide the receiver object from
Marshal, as DRb depends on it.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63137 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* error.c (nometh_err_initialize): do not shirtcut rb_call_super,
to push proper control frame. [ruby-dev:50522] [Bug #14670]
* error.c (rb_nomethod_err_new): allocate and initialize a new
NoMethodError instance.
* vm_eval.c (rb_make_no_method_exception): create a new exception
instance directly without method calls, to prevent influence of
ruby level method definitions, which can cause an unpredictable
behavior, e.g., infinite recursion.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63136 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* error.c (rb_warn_m): prepend the string "warning: " if uplevel
keyword is given, even if caller file and line information are
not available.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63062 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* error.c (rb_exc_new, rb_exc_new_str): instantiate exception
object directly without Exception.new method call.
Redefinition of class method `new` is an outdated style, and
internal exceptions should not be affected by it.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62500 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
to test JIT with `VM_CHECK_MODE=1`
It's failing on CI which enables VM_CHECK_MODE.
: 1)
: TestJIT#test_jit [/home/ko1/ruby/src/trunk-vm-asserts/test/ruby/test_jit.rb:10]:
: Expected 1 times of JIT success, but succeeded 0 times.
: 2)
: TestJIT#test_jit_output [/home/ko1/ruby/src/trunk-vm-asserts/test/ruby/test_jit.rb:18]:
: Expected /^JIT success \(\d+\.\dms\): block in <main>@-e:1 -> .+_ruby_mjit_p\d+u\d+\.c$/ to match "MJIT warning: failure in loading code from '/tmp/_ruby_mjit_p9896u0.so': /tmp/_ruby_mjit
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62296 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
which has been developed by Takashi Kokubun <takashikkbn@gmail> as
YARV-MJIT. Many of its bugs are fixed by wanabe <s.wanabe@gmail.com>.
This JIT compiler is designed to be a safe migration path to introduce
JIT compiler to MRI. So this commit does not include any bytecode
changes or dynamic instruction modifications, which are done in original
MJIT.
This commit even strips off some aggressive optimizations from
YARV-MJIT, and thus it's slower than YARV-MJIT too. But it's still
fairly faster than Ruby 2.5 in some benchmarks (attached below).
Note that this JIT compiler passes `make test`, `make test-all`, `make
test-spec` without JIT, and even with JIT. Not only it's perfectly safe
with JIT disabled because it does not replace VM instructions unlike
MJIT, but also with JIT enabled it stably runs Ruby applications
including Rails applications.
I'm expecting this version as just "initial" JIT compiler. I have many
optimization ideas which are skipped for initial merging, and you may
easily replace this JIT compiler with a faster one by just replacing
mjit_compile.c. `mjit_compile` interface is designed for the purpose.
common.mk: update dependencies for mjit_compile.c.
internal.h: declare `rb_vm_insn_addr2insn` for MJIT.
vm.c: exclude some definitions if `-DMJIT_HEADER` is provided to
compiler. This avoids to include some functions which take a long time
to compile, e.g. vm_exec_core. Some of the purpose is achieved in
transform_mjit_header.rb (see `IGNORED_FUNCTIONS`) but others are
manually resolved for now. Load mjit_helper.h for MJIT header.
mjit_helper.h: New. This is a file used only by JIT-ed code. I'll
refactor `mjit_call_cfunc` later.
vm_eval.c: add some #ifdef switches to skip compiling some functions
like Init_vm_eval.
win32/mkexports.rb: export thread/ec functions, which are used by MJIT.
include/ruby/defines.h: add MJIT_FUNC_EXPORTED macro alis to clarify
that a function is exported only for MJIT.
array.c: export a function used by MJIT.
bignum.c: ditto.
class.c: ditto.
compile.c: ditto.
error.c: ditto.
gc.c: ditto.
hash.c: ditto.
iseq.c: ditto.
numeric.c: ditto.
object.c: ditto.
proc.c: ditto.
re.c: ditto.
st.c: ditto.
string.c: ditto.
thread.c: ditto.
variable.c: ditto.
vm_backtrace.c: ditto.
vm_insnhelper.c: ditto.
vm_method.c: ditto.
I would like to improve maintainability of function exports, but I
believe this way is acceptable as initial merging if we clarify the
new exports are for MJIT (so that we can use them as TODO list to fix)
and add unit tests to detect unresolved symbols.
I'll add unit tests of JIT compilations in succeeding commits.
Author: Takashi Kokubun <takashikkbn@gmail.com>
Contributor: wanabe <s.wanabe@gmail.com>
Part of [Feature #14235]
---
* Known issues
* Code generated by gcc is faster than clang. The benchmark may be worse
in macOS. Following benchmark result is provided by gcc w/ Linux.
* Performance is decreased when Google Chrome is running
* JIT can work on MinGW, but it doesn't improve performance at least
in short running benchmark.
* Currently it doesn't perform well with Rails. We'll try to fix this
before release.
---
* Benchmark reslts
Benchmarked with:
Intel 4.0GHz i7-4790K with 16GB memory under x86-64 Ubuntu 8 Cores
- 2.0.0-p0: Ruby 2.0.0-p0
- r62186: Ruby trunk (early 2.6.0), before MJIT changes
- JIT off: On this commit, but without `--jit` option
- JIT on: On this commit, and with `--jit` option
** Optcarrot fps
Benchmark: https://github.com/mame/optcarrot
| |2.0.0-p0 |r62186 |JIT off |JIT on |
|:--------|:--------|:--------|:--------|:--------|
|fps |37.32 |51.46 |51.31 |58.88 |
|vs 2.0.0 |1.00x |1.38x |1.37x |1.58x |
** MJIT benchmarks
Benchmark: https://github.com/benchmark-driver/mjit-benchmarks
(Original: https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch/MJIT-benchmarks)
| |2.0.0-p0 |r62186 |JIT off |JIT on |
|:----------|:--------|:--------|:--------|:--------|
|aread |1.00 |1.09 |1.07 |2.19 |
|aref |1.00 |1.13 |1.11 |2.22 |
|aset |1.00 |1.50 |1.45 |2.64 |
|awrite |1.00 |1.17 |1.13 |2.20 |
|call |1.00 |1.29 |1.26 |2.02 |
|const2 |1.00 |1.10 |1.10 |2.19 |
|const |1.00 |1.11 |1.10 |2.19 |
|fannk |1.00 |1.04 |1.02 |1.00 |
|fib |1.00 |1.32 |1.31 |1.84 |
|ivread |1.00 |1.13 |1.12 |2.43 |
|ivwrite |1.00 |1.23 |1.21 |2.40 |
|mandelbrot |1.00 |1.13 |1.16 |1.28 |
|meteor |1.00 |2.97 |2.92 |3.17 |
|nbody |1.00 |1.17 |1.15 |1.49 |
|nest-ntimes|1.00 |1.22 |1.20 |1.39 |
|nest-while |1.00 |1.10 |1.10 |1.37 |
|norm |1.00 |1.18 |1.16 |1.24 |
|nsvb |1.00 |1.16 |1.16 |1.17 |
|red-black |1.00 |1.02 |0.99 |1.12 |
|sieve |1.00 |1.30 |1.28 |1.62 |
|trees |1.00 |1.14 |1.13 |1.19 |
|while |1.00 |1.12 |1.11 |2.41 |
** Discourse's script/bench.rb
Benchmark: https://github.com/discourse/discourse/blob/v1.8.7/script/bench.rb
NOTE: Rails performance was somehow a little degraded with JIT for now.
We should fix this.
(At least I know opt_aref is performing badly in JIT and I have an idea
to fix it. Please wait for the fix.)
*** JIT off
Your Results: (note for timings- percentile is first, duration is second in millisecs)
categories_admin:
50: 17
75: 18
90: 22
99: 29
home_admin:
50: 21
75: 21
90: 27
99: 40
topic_admin:
50: 17
75: 18
90: 22
99: 32
categories:
50: 35
75: 41
90: 43
99: 77
home:
50: 39
75: 46
90: 49
99: 95
topic:
50: 46
75: 52
90: 56
99: 101
*** JIT on
Your Results: (note for timings- percentile is first, duration is second in millisecs)
categories_admin:
50: 19
75: 21
90: 25
99: 33
home_admin:
50: 24
75: 26
90: 30
99: 35
topic_admin:
50: 19
75: 20
90: 25
99: 30
categories:
50: 40
75: 44
90: 48
99: 76
home:
50: 42
75: 48
90: 51
99: 89
topic:
50: 49
75: 55
90: 58
99: 99
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62197 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
`NameError.new(1,2,3)` raises
`wrong number of arguments (given 2, expected 0..1) (ArgumentError)`
in `StrandardError#initialize`, so NameError can't accept 3 or more arguments.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62159 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Jeremy Evans
Nobuyoshi Nakada
Koichi Sasada
Steven Harman
git
Luke Gruber
ktsj
nobu
naruse
kazu
eregon
stomar
k0kubun