We can check the function pointer passed to rb_define_private_method
like how we do so in rb_define_method. Doing so revealed some
problematic usages of rb_obj_dummy. They had to be split according
to their arity.
We can check the function pointer passed to
rb_define_protected_method like how we do so in rb_define_method.
This changeset revealed no prototypes mismatches.
We can check the function pointer passed to rb_define_method_id
like how we do so in rb_define_method. This method is relatively
rarely used so there are less problems found than the other APIs.
We can check the function pointer passed to rb_define_global_function
like we do so in rb_define_method. It turns out that almost anybody
is misunderstanding the API.
We can check the function pointer passed to rb_define_module_function
like how we do so in rb_define_method. The difference is that this
changeset reveales lots of atiry mismatches.
The rb_define_method function takes a pointer to ANYARGS-ed functions,
which in fact varies 18 different prototypes. We still need to
preserve ANYARGS for storages but why not check the consistencies if
possible.
Q&As:
Q: Where did the magic number "18" came from in the description above?
A: Count the case branch of vm_method.c:call_cfunc_invoker_func().
Note also that the 18 branches has lasted for at least 25 years.
See also 200e0ee2fd.
Q: What is this __weakref__ thing?
A: That is a kind of function overloading mechanism that GCC provides.
In this case for instance rb_define_method0 is an alias of
rb_define_method, with a strong type.
Q: What is this __transparent_union__ thing?
A: That is another kind of function overloading mechanism that GCC
provides. In this case the attributed function pointer is either
VALUE(*)(int,VALUE*,VALUE) or VALUE(*)(int,const VALUE*,VALUE).
This is better than void* or ANYARGS because we can reject all
other possibilities than the two.
Q: What does this rb_define_method macro mean?
A: It selects appropriate alias of the rb_define_method function,
depending on the arity.
Q: Why the prototype change of rb_f_notimplement?
A: Function pointer to rb_f_notimplement is special cased in
vm_method.c:rb_add_method_cfunc(). That should be handled by the
__builtin_choose_expr chain inside of rb_define_method macro
expansion. In order to do so, comparison like (func ==
rb_f_notimplement) is inappropriate for __builtin_choose_expr's
expression (which must be a compile-time integer constant but the
address of rb_f_notimplement is not fixed until the linker). So
instead we are using __builtin_types_compatible_p, and in doing so
we need to distinguish rb_f_notimplement from others, by type.
This reverts commit 6454808c52.
It is no longer needed, as `VCS::SVN#get_revisions` now returns
`Integer` as revision numbers, and `short_revision` should deal
with it.
`rb_ast_t` holds a reference to this object, so it should mark the
object. Currently it is relying on the `mark_ary` on `node_buffer` to
ensure that the object stays alive. But since the array internals can
move, this could cause a segv if compaction impacts the array.
To fix "gcc: -lgcc: linker input file unused because linking not done" in
https://rubyci.org/logs/rubyci.s3.amazonaws.com/openbsd65/ruby-master/log/20190826T200009Z.log.html.gz
Still I'm intentionally leaving CC_DLDFLAGS_ARGS because making compiler
options different might result in compile/link failure. (Of course
CC_DLDFLAGS_ARGS usually should not have compiler options, but it might
include by bad configure setup)
The same problem may exist in MJIT_LIBS used inside CC_LIBS as well, but
I just ignored that case because it impacts only MinGW / cygwin, hoping
that their users do not perform a wrong configure.
a little.
Doing both `git clone --depth=1` and `git reset --hard ${sha}` does not
make sense (the latter command either does nothing or just fails), so I
added non-1 value as a depth.
Maybe we don't need depth=50 for pull_request and schedule, so it's 10
for now.