<headius>
ok these test are failing on master... it may be that master was not running with indy for the MRI quite correctly
<headius>
not sure how... the diff doesn't show anything changing substantially
<headius>
enebo: ok so one of these I need some input on
<headius>
IO#advise takes 1 to 3 arguments... the test that fails with indy passes 4 arguments expecting an argument error, but the implementation that takes IRubyObject[] does not actually do an arity check so it fails
<headius>
when calling through the DynamicMethod wrappers, the arity check happens automatically, but indy bypasses that
<headius>
so the question is whether we should always be arity-checking inside IRubyObject[] methods or whether we should always expect the caller to check
<enebo[m]>
hmm
<headius>
keeping in mind that the current logic would also fail to check arity if called normally from Java
<enebo[m]>
I generally thought we did
<headius>
we do generally but it has not been a rule and we have places (at least one!) that don't
<enebo[m]>
but I think we should just for the Java calling perspective
<enebo[m]>
yeah
<headius>
yeah that gels with what I was thinking
<headius>
it may be worth auditing all such methods... and also removing from the DynamicMethod invokers, since it will be double-checking in some cases now
<headius>
arity splitting avoids this of course
<enebo[m]>
so just remove double check if IRubyObject[]
<enebo[m]>
makes sense
<headius>
right
<headius>
I still have no explanation for why these indy mri:core tests are not failing in master CI but they do fail on master locally
<headius>
I'll clean these up and then get gha speed improvements landed