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.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This function has only one call site
so adding appropriate prototype is trivial.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. There is only one usage of
MEMO::u3::func in load.c (where void Init_Foobar(vodi) is registered)
so why not just be explicit.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit adds a function
prototype for rb_ivar_foreach. Luckily this change revealed no
problematic usage of the function.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit adds function prototypes
for rb_hash_foreach / st_foreach_safe. Also fixes some prototype
mismatches.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit uses rb_gvar_getter_t /
rb_gvar_setter_t for rb_define_hooked_variable /
rb_define_virtual_variable which revealed lots of function prototype
inconsistencies. Some of them were literally decades old, going back
to dda5dc00cf.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit adds function prototypes
for struct st_hash_type. Honestly I don't understand why they were
commented out at the first place.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
st_foreach. I strongly believe that this commit should have had come
with b0af0592fd, which added extra
parameter to st_foreach callbacks.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_thread_create, which seems very safe to do.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_proc_new / rb_fiber_new, and applies RB_BLOCK_CALL_FUNC_ARGLIST
wherever necessary.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_catch, and fixes some bugs revealed by that.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_ensure, which also revealed many arity / type mismatches.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_rescue / rb_rescue2, which revealed many arity / type mismatches.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
struct vm_ifunc, but in doing so we also have to decouple the usage
of this struct in compile.c, which (I think) is an abuse of ANYARGS.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. Let's start from making
rb_block_call_func_t strict, and apply RB_BLOCK_CALL_FUNC_ARGLIST liberally.
```
In file included from sprintf.c:1256:
./vsnprintf.c:833:8: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int]
IS_PRI_EXTRA_MARK(fmt)) {
^~~~~~~~~~~~~~~~~~~~~~
./vsnprintf.c:826:34: note: expanded from macro 'IS_PRI_EXTRA_MARK'
strncmp((s)+1, PRI_EXTRA_MARK+1, \
~~~~~~~~~~~~~~^~
./vsnprintf.c:833:8: note: use array indexing to silence this warning
./vsnprintf.c:826:34: note: expanded from macro 'IS_PRI_EXTRA_MARK'
strncmp((s)+1, PRI_EXTRA_MARK+1, \
^
1 warning generated.
```
I'm afraid the keys to this hash are just integers, and those integers
may look like VALUE pointers when they are not. Since we don't mark the
keys to this hash, it's probably safe to say that none of them have
moved, so we shouldn't try to update the references either.