* YJIT: add context cache hits stat
This stat should make more sense when it comes to interpreting
the effectiveness of the cache on large deployed apps.
Now that we're using the inline predicate functions everywhere, the only
remaining use of the RVALUE_?_BITMAP macros is inside their respective
inline function, so we can remove them.
This function loops twice through the array of size pools. Once to set
up the pages list, and then again later on in the function to set the
allocatable_pages count.
We don't do anything with the size pools in between the invocation of
these loops that will affect the size pools, so this commit removes the
second loop and moves the allocatable_pages count update into the first
loop.
`SPEC_TEMP_DIR` is not present until `tmp()` method is called
on parallel run. In this case `tmp()` is called with `File.umask = 0`.
This patch makes `SPEC_TEMP_DIR` before `File.umask = 0`.
To solve the issue essentially, I think `SPEC_TEMP_DIR` should be
prepared at the beginning of parallel process.
The warning category should be enabled if we want to call
`Warning.warn`.
This commit speeds up the following benchmark:
```ruby
eval "def test; " +
1000.times.map { "' '.chomp!" }.join(";") + "; end"
def run_benchmark count
i = 0
while i < count
start = Process.clock_gettime(Process::CLOCK_MONOTONIC)
yield
ms = Process.clock_gettime(Process::CLOCK_MONOTONIC) - start
puts "itr ##{i}: #{(ms * 1000).to_i}ms"
i += 1
end
end
run_benchmark(25) do
250.times do
test
end
end
```
On `master` this runs at about 92ms per iteration. With this patch, it
is 7ms per iteration.
[Bug #20573]
Some of the places in Redmine (e.g. Associated revisions) print
revisions using only 8 characters. Even when I copied a revision from
there, I want to prepend commit: in the message.
When doing out-of-source builds I often end up wanting to use gdb from
inside a build directory.
Currently if I do that the `.gdbinit` in the ruby source directory is
not read.
Attempting to manually load the `.gdbinit` from the Ruby source
directory errors because of hard coded file-paths that assume we're
running gdb from inside the source tree.
Adding the `-s` flag to the `source` command when loading relative files
signals to gdb to search in the source search path for the required
file, rather than just the current directory.
This allows me to use a custom `.gdbinit` from my build directory that
sets the correct source directory and then loads the Ruby `.gdbinit`.
```
dir ../src
source ../src/.gdbinit
```
I cannot receive Travis's notification via jaruga@ruby-lang.org, while another
committer with their @ruby-lang.org email can receive the notification.
The issue is my ruby-lang.org email address specific.
So far we haven't seen the root cause even with the Travis support's help.
Because of that, I change the email address to my personal email address.
This changes the automatic detection of -fstack-protector,
-D_FORTIFY_SOURCE, and -mbranch-protection to write to $hardenflags
instead of $XCFLAGS. The definition of $cflags is changed to
"$hardenflags $orig_cflags $optflags $debugflags $warnflags" to match.
Furthermore, these flags are _prepended_ to $hardenflags, rather than
appended.
The implications of doing this are as follows:
* If a CRuby builder specifies cflags="-mbranch-protection=foobar" at
the ./configure script, and the configure script detects that
-mbranch-protection=pac-ret is accepted, then GCC will be invoked as
"gcc -mbranch-protection=pac-ret -mbranch-protection=foobar". Since
the last flags take precedence, that means that user-supplied values
of these flags in $cflags will take priority.
* Likewise, if a CRuby builder explicitly specifies
"hardenflags=-mbranch-protection=foobar", because we _prepend_ to
$hardenflags in our autoconf script, we will still invoke GCC as
"gcc -mbranch-protection=pac-ret -mbranch-protection=foobar".
* If a CRuby builder specifies CFLAGS="..." at the configure line,
automatic detection of hardening flags is ignored as before.
* C extensions will _also_ be built with hardening flags now as well
(this was not the case by default before because the detected flags
went into $XCFLAGS).
Additionally, as part of this work, I changed how the detection of
PAC/BTI in Context.S works. Rather than appending the autodetected
option to ASFLAGS, we simply compile a set of test programs with the
actual CFLAGS in use to determine what PAC/BTI settings were actually
chosen by the builder. Context.S is made aware of these choices through
some custom macros.
The result of this work is that:
* Ruby will continue to choose some sensible defaults for hardening
options for the C compiler
* Distributors are able to specify CFLAGS that are consistent with their
distribution and override these defaults
* Context.S will react to whatever -mbranch-protection is actually in
use, not what was autodetected
* Extensions get built with hardening flags too.
[Bug #20154]
[Bug #20520]
```
1)
Dir.mktmpdir when passed a block yields the path to the passed block ERROR
ArgumentError: parent directory is world writable but not sticky: /tmp/rubytest.wlu5cs_11
/tmp/ruby/src/trunk/lib/tmpdir.rb:113:in 'Dir.mktmpdir'
/tmp/ruby/src/trunk/spec/ruby/library/tmpdir/dir/mktmpdir_spec.rb:39:in 'block (2 levels) in <top (required)>'
```
This weird error comes from world-writable (and not sticky) directory
of `SPEC_TEMP_DIR`.
This patch checks `SPEC_TEMP_DIR` is not world-writable if exists
and `File.umask` contains o+w mask.
```
1)
TracePoint#inspect returns a String showing the event, method, path and line for a :call event FAILED
Expected "#<TracePoint:call 'call' /tmp/ruby/src/trunk/spec/ruby/core/objectspace/define_finalizer_spec.rb:33>" =~ /\A#<TracePoint:call [`']trace_point_spec_test_call' \/tmp\/ruby\/src\/trunk\/spec\/ruby\/core\/tracepoint\/inspect_spec.rb:43>\z/
to be truthy but was nil
```
This kind of failures comes because of finaizers.
So check the current file or not.
`RUBY_FUNC_EXPORTED` is working on Windows since 906a86e4de.
And as .def files are not processed by the preprocessor, it is less
flexible than `RUBY_FUNC_EXPORTED`, (e.g., select symbols by
conditions such as ruby version).