`rb_objspace_call_finalizer` creates zombies, but does not do the correct accounting (it should increment `heap_pages_final_slots` whenever it creates a zombie). When we do correct accounting, `heap_pages_final_slots` should never underflow (the check for underflow was introduced in 39725a4db6).
The implementation moves the accounting from the functions that call `make_zombie` into `make_zombie` itself, which reduces code duplication.
For a regular block, accepting two arguments is fine as the array
will be autosplatted. However, a lambda that accepts two arguments
will not work.
We could change the implementation to yield two arguments instead
of an array with a single argument, but that would be less backwards
compatible.
I'm only changing the call-seq to be precise, other examples pass
a literal block that accepts two arguments, and I left those alone
as that will be the most common usage.
Fixes [Bug #17094]
Added some cross compilers that we can run on GitHub Workflow runner
environments. Because they are cross compilers we cannot run the
generated binary. The added matrix are compile-only.
If the thread for the current EC has been killed, don't check
the VM ptr for the EC (which gets it via the thread), as that will
have already been freed.
Fixes [Bug #16907]
AC_PROG_CC_C99 calls AC_PROC_CC, which calls _AC_PROG_CC_G, which sets
default CFLAGS, whose contents are not customisable. We don't welcome
this behaviour.
The exact same thing happens for CXXFLAGS in AC_PROG_CXX.
`llvm-strip-7` is a sane valid strip command that LLVM 7 ships, albeit
it does not understand `--version`. It is a bad idea to check that
option. Instead just see if the command actually strips something. A
copy of `/bin/sh` should suffice. That file must be ubiquitous.
In case of cross-compilation, GCC might provide its own linker. Its
behaviour seems slightly different from that of gcc(1). This is not a
big deal for normal situations, but the difference can cause libtool to
go mad.
We ship bundled libffi for windows users, and libffi uses libtool. If
we use cross-compiler version of gcc instead of its ld conterpart, we
fail to compile fiddle. That should not be what we want.
Historically `$program_transform_name` has been put in front of
`AC_CANONICAL_TARGET`. Previous commit changes it, which affects the
name of generated ruby binary when cross-compiling. I _guess_ the
historical behaviour is a bug (name of ruby binary shall honour --target
configure option I think), but anyways here I preserve that questionable
way.
These days as link-time optimisations spread accross compilers, they
tend to ship their own version of ld, ar, etc. Why not detect such
things if any. Users can select compilers by ./configure --with-gcc=
whatever, or select individual tool by e.g. ./configure NM=whatever.
The added AC_ARG_VAR macros enrich ./configure --help output.
Because we check HAVE_STMT_AND_DECL_IN_EXPR in configure, it is peoven
to work in C. But C++ situation can be different. Oracle Developer
Studio is another example of such things.
Oracle Developer Studio's C++ preprocessor started to understand
__has_cpp_attribute since version 12.5, and is broken. After looking
around for a while I found Boost and ICU also had this issue before.
Let me add workaround for it.
Lars Kanis
Peter Zhu
git
Burdette Lamar
Hiroshi SHIBATA
Lars Kanis
Jeremy Evans
Kazuhiro NISHIYAMA
Yusuke Endoh
卜部昌平
aycabta
Marc-Andre Lafortune
Jean Boussier