Avoid Interop TypeOfNode specializations for EnsoObject

[JaroslavTulach]

Pull Request Description

Fixing inconsistency in @Specialization in TypeOfNode discovered by Radek. Testing the node in two situations - directly and after being primed to access interop TruffleObject first.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Java,
  style guides.- All code has been tested:
  • Unit tests have been written where possible.

[radeusgd]

Thanks for such a quick fix!

[JaroslavTulach]

Per suggestion of Christian Humber:

you should use @Bind("$node") for context references in libraries instead of arbitrary nodes. In general they might not be adoptable:

  @ExportLibrary(value = TypesLibrary.class, receiverType = Long.class)
    public static class DefaultLongExports {

        @ExportMessage
        static boolean hasType(Long receiver) {
            return true;
        }

        @ExportMessage
        static Class<?> getType(Long receiver, @Bind("$node") Node node) {
            SLContext.get(node);
            return Long.class;
        }
    }

we don't have to use @Cached("1") int ignore anymore...

[JaroslavTulach]

... if it works. Sometimes it doesn't work and I had to add the @Cached("1") int ignore trick back.

[hubertp]

Don't we have the same problem with long and double?

[JaroslavTulach]

Don't we have the same problem with long and double?

I've added ValuesGenerator based test in fb59778 and both long and double seem to work.