[interop] Modules claim to have source locations, but they're actually "null"

[fniephaus]

Here're steps for reproduction:

$ polyglot --jvm --shell
GraalVM MultiLanguage Shell 21.0.0
Copyright (c) 2013-2020, Oracle and/or its affiliates
  Ruby version 2.7.2
  Squeak/Smalltalk version 21.1.0-dev
ruby> Truffle::Interop.has_source_location?(Array)
true
ruby> Truffle::Interop.source_location(Array)
null
ruby> Truffle::Interop.has_source_location?(ObjectSpace)
true
ruby> Truffle::Interop.source_location(ObjectSpace)
null

[eregon]

Right, we should probably return false for those cases, or return an unavailable SourceSection instead.
I'm not sure which one is better, the check for null means also a check in getSourceLocation + UnsupportedMessageException if null, which seems quite verbose.

InteropLibrary.Asserts actually checks getSourceLocation is not null if hasSourceLocation, but that doesn't seem run by the TCKs or our tests currently.

[eregon]

@bjfish Could you fix this? I think returning an unavailable SourceSection is better for those cases.

[eregon]

For Truffle::Interop.source_location I wonder if we should return a host object for SourceSection (as currently), or a [String, Integer] array like e.g. Method#source_location does in Ruby.
@fniephaus Any opinion?

[fniephaus]

I'd say it should return a host object, because it is essentially just returning from InteropLibrary#getSourceLocation(Object receiver). If a [String, Integer] array is needed, maybe introduce a helper (e.g., Truffle::Interop.ruby_source_location)?

[chumer]

Host objects are not a good choice for this. They are logically separate class loaders.
If you want to represent a source location in the guest language better use your own TruffleObject.

[fniephaus]

Right, if you want to expose them properly for users. I thought users are not encouraged to use Truffle::Interop, it's more like a utility for direct access to the interoperability protocol. And in that case, I'd try to forward values as they are.

[chumer]

Host interop for that is still not a good choice. As access privileges to the host can be restricted.
Note that the truffle source section class is not visible to a host and therefore access privilege checks will always return false.
If I would have the time to push for it then Env.asGuestValue would already be deprecated. But we have some work to do to make that happen.

[eregon]

I thought users are not encouraged to use Truffle::Interop, it's more like a utility for direct access to the interoperability protocol.

Yes, Truffle::Interop should only be used if there is no other way essentially.

And in that case, I'd try to forward values as they are.

Almost all Truffle::Interop methods return either a Ruby value/object or a foreign object (if that's what the InteropLibrary message returns).
A host object is kind of weird here, because the program might not do any interop with the host language, and host interop might be disabled.
Also, it doesn't seem to work in --native mode (by default, without extra configuration at least):

$ ruby -e 'class C; end; p Truffle::Interop.members Truffle::Interop.source_location(C)'
[]

Even on JVM it doesn't seem to work:

$ jt ruby --polyglot -e 'class C; end; p Truffle::Interop.members Truffle::Interop.source_location(C)'
[]

[eregon]

Fixed in 8cd2203.