* ast.c: I created a new C source code file with tabs and spaces mixed
format by mistake. Currently we move to spaces only.
Surely we agreed not to batch update. But ast.c is a new
source code. So please forgive me to change the format before
many changes are committed this file.
I'm sorry about my mistake.
ref [Bug #14246]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63586 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I'm not entirely sure why, but SIGTTOU pauses the test
when running test-all in parallel.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63583 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
rb_gc_mark_encodings has been empty for a decade
(since r17875 / 28b216ac45).
Just remove it and its only caller in gc.c
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63582 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
For the current cases, a few string substitions is enough to
make dtrace(1) scripts work with stap(1). For more complex
scripts (maybe in the future), we may pass a hash with
implementation-specific scripts.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63581 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Since [Feature #14104], "trace" instructions are no
longer emitted by default, so we must enable them explicitly
for function tracing to work.
[ruby-core:85965]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63580 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Don't output method cache clearing at startup since
it causes dtrace to drop output and break the test.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63579 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Nowadays we create empty arrays in the parse/compile
phase which gave us lineno==0.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63578 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
RbConfig::TOPDIR points to my installation prefix on my FreeBSD
and GNU/Linux systems, so there's no way miniruby exists, there.
In case we don't have miniruby, --disable=gems anyways to reduce
dtrace overhead.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63577 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
GNU/Hurd has writev(2) but does not define IOV_MAX
[ruby-core:87417] [Bug #14827]
Reported-by: Paul Sonnenschein
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63576 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Every time I look at gc.c, I get confused by argument ordering:
gc_start(..., TRUE, TRUE, FALSE, ...)
gc_start(..., FALSE, FALSE, FALSE, ... )
While we do not have kwargs in C, we can use flags to improve readability:
gc_start(...,
GPR_FLAG_FULL_MARK | GPR_FLAG_IMMEDIATE_MARK |
GPR_FLAG_IMMEDIATE_SWEEP | ...)
[ruby-core:87311] [Misc #14798]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63575 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
We may add gc_*_continue calls in a few more places, and adding
more #ifdefs around those is ugly. For now, this makes the
heap_prepare function look better.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63573 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* include/ruby/missing.h (isinf, isnan): For non-C++ programs,
defined(__cplusplus) may be needed before using __cplusplus.
[Bug #14816]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63572 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
- `isnan` is something relatively new. We need to provide one for
those systems without it. However:
- X/Open defines `int isnan(double)`. Note the `int`.
- C99 defines `isnan(x)` to be a macro.
- C++11 nukes them all, undefines all the "masking macro"s, and
defines its own `bool isnan(double)`. Note the `bool`.
- In C++, `int isnan(double)` and `bool isnan(double)` are
incompatible.
- So the mess.
[Bug #14816][ruby-core:87364]
further reading: https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think/
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63571 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Repeatedly checking for malloc_limit_max in gc_reset_malloc_info
is unnecessary, check and set it once during initialization
in ruby_gc_set_params to simplify the hotter path
* gc.c (gc_reset_malloc_info): remove zero check
(ruby_gc_set_params): treat malloc_limit_max==0 as SIZE_MAX
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63569 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* test/-ext-/ast/test_ast.rb: This test file
has not depended C extension since r63534,
so move to 'test/ruby/'.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63568 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
"Real" time is too unstable on my systems, hopefully counting
only CPU time can gain more reliable benchmark results.
[ruby-core:87362] [Feature #14815]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63564 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It can be used to get the parameters' information of method and block.
There was no way to get block parameters.
It was possible but ineffective to get method parameters via Method
object: `tp.defined_class.method(tp.method_id).parameters`
TracePoint#parameters allows us to get the information easily.
[Feature #14694]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63562 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* enum.c (imemo_count_up, imemo_count_value): promote the counter
value to a bignum on overflow. [Bug #14805]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63554 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Some operating systems will work without calling
pthread_condattr_init, but some won't (such as OpenBSD). Prior
to r63238, pthread_condattr_init was always called before
calling pthread_condattr_setclock.
From: Jeremy Evans <code@jeremyevans.net>
[ruby-core:87345] [Ruby trunk Bug#14807]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63548 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Most (if not all) architectures have instructions for comparing
against zero, allowing compilers to generate more compact code.
Other MEMOP_TYPE_* enum values are not compared in hot paths,
but MEMOP_TYPE_MALLOC is checked in objspace_malloc_increase
text data bss dec hex filename
84088 264 3664 88016 157d0 gc-before.o
83784 264 3664 87712 156a0 gc.o
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63546 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This allows user to specify any name in `--with-so-name` that might
cause a name clash with LIBRUBY_ALIASES on the platform.
Without this, for example, configuring with `--with-soname=ruby
--enable-shared` on macOS would end up running `ln -sf libruby.dylib
libruby.dylib` only to fail with the following error in installation:
```
make[2]: stat: libruby.dylib: Too many levels of symbolic links
```
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63544 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* string.c (rb_str_aset): prefer BUILTIN_TYPE over TYPE after
SPECIAL_CONST_P check.
* string.c (rb_str_start_with): prefer RB_TYPE_P over switch by
TYPE.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63543 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* vm_args.c (setup_parameters_complex): refine the warning message
for a splat hash which was passed to a single variable instead
of keyword arguments. this behavior will be changed when the
"real" keyword argument is introduced in the future.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63540 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* test/ruby/test_rubyoptions.rb: Process.wait with WNOHANG returns
nil while the target process is alive.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63538 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* test/ruby/test_rubyoptions.rb: wait for setting process title
until the child process dies, in the case of extra heavy loads.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63537 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
yui-knk
normal
svn
ngoto
shyouhei
mame
hsbt
nobu
naruse
knu