Throw a runtime error if #binding is called from a C extensions module (non-ruby frame)

[manefz]

Part of #3039

Fixes [easy, java] Kernel#binding raises RuntimeError if called from a non-Ruby frame (such as a method defined in C). [[Bug #18487](https://bugs.ruby-lang.org/issues/18487)]

Following what was done in Cruby 3.2 PR here
Raises an error if the frame that is called from is not Ruby.

Co-authored with @rwstauner

[rwstauner]

For reference it seems tryGetMethod is looking up the ruby method that is the context of the frame calling binding.
So in the case of the test
https://github.com/oracle/truffleruby/blob/0c3f184c762ed0b5cce42d5b33f8c1b8bcb46658/spec/ruby/optional/capi/binding_spec.rb#L14
is backed by
https://github.com/oracle/truffleruby/blob/0c3f184c762ed0b5cce42d5b33f8c1b8bcb46658/spec/ruby/optional/capi/ext/binding_spec.c#L8-L9
and the method of the caller frame then points to CExt#rb_funcallv
https://github.com/oracle/truffleruby/blob/0c3f184c762ed0b5cce42d5b33f8c1b8bcb46658/lib/truffle/truffle/cext.rb#L1059

[rwstauner]

I'm not sure in what scenario tryGetMethod might return null

[rwstauner]

There's probably also a better check here than doing a string comparison on the method's module, but we hadn't found anything.
Any pointers on what else we might be able to use for this?

[eregon]

There is org.truffleruby.core.CoreLibrary#truffleCExtModule and then it can be compared with ==.

But comparing on the module is hacky, because it means every Truffle::CExt method can no longer access binding.
Which seems a problem notably for:
https://github.com/oracle/truffleruby/blob/610cea3302a7302c5ec3efd1a6f89b26467d04c3/lib/truffle/truffle/cext.rb#L2039-L2041

That can be worked around, but it shows it's rather hacky.

I'm not sure what's a good solution for detecting C ext methods, maybe/probably we should define Truffle::CExt#rb_define_method in Java eventually. Or find another way to mark those.

But I think for now a more useful check would be to check if sourceSection == CoreLibrary.JAVA_CORE_SOURCE_SECTION, which means a method defined in Java.
Getting a binding from there will always be empty, which seems not useful, so that seems the corresponding case to CRuby having methods defined in C and for which no meaningful binding can be given.

An example test for that is:

$ ruby -e 'p method(:binding).call'
-e:1:in `binding': Cannot create Binding object for non-Ruby caller (RuntimeError)

Currently on TruffleRuby it's:

$ ruby -e 'p method(:binding).call'
#<Binding:0xc8>
$ ruby -e 'p method(:binding).call.local_variables'
[]

[eregon]

BTW for the existing spec in spec/ruby/optional/capi/binding_spec.rb I would think we already raise an error for that case, because the callerFrame should be null in that case since it is a call from LLVM/Sulong.
But maybe there is something in between which means there is a frame somehow.

[rwstauner]

On the master branch this spec fails with

CApiBindingSpecs Kernel#binding raises when called from C FAILED
Expected RuntimeError but no exception was raised (#<Binding:0x368> was returned)

I loaded a debugger to check the sourceSection and it is not the same as CoreLibrary.JAVA_CORE_SOURCE_SECTION.

This is what I see:

If I use a different ruby script that calls binding from ruby code the sourceSection here doesn't have any different properties from the above (other than the path) that I can see 🤔

[eregon]

Right, so the SourceSection there is https://github.com/oracle/truffleruby/blob/677ac08b296b086a7d6ede73f6cbebe7c8027a6a/lib/truffle/truffle/cext.rb#L1060

So let's not try to pass this specific spec for now, because it would require changing rb_funcallv which is out of scope.

But instead let's add another spec, using method(:binding).call, and that should raise the RuntimeError, and that one we can use the check for JAVA_CORE_SOURCE_SECTION.

[eregon]

One thing worth trying to pass that C API spec would be to change SendWithoutCExtLockBaseNode to call callWithFrameAndBlock without a frame (so with null instead). But that may have other side effects which might be undesirable.

[eregon]

^ but the frame was added back in 6fbb9ee probably for 796df16.
And 9c0f7ce seems also related.
So I think best to not touch that for now.

[rwstauner]

#3449 Is an alternative implementation that uses something similar to the commit you pointed to 9c0f7ce

[eregon]

Could you use an InlinedBranchProfile errorProfile here, so this branch is only explored by the JIT if it ever happened? (that way it can also optimize better because it knows there is no throw)