Create static wrappers for builtin types

[hubertp]

Pull Request Description

#3764 introduced static wrappers for instance methods. Except it had a limitation to only be allowed for types with at least a single constructor.
That excluded builtin types as well which, by default, don't have them. This limitation is problematic for Array/Vector consolidation and makes builtin types somehow second-citizens.

This change lifts the limitation for builtin types only. Note that we do want to share the implementation of the generated builtin methods. At the same time due to the additional argument we have to adjust the starting index of the arguments.
This change avoids messing with the existing dispatch logic, to avoid unnecessary complexity.

As a result it is now possible to call builtin types' instance methods, statically:

  arr = Array.new_1 42
  Array.length arr

That would previously lead to missing method exception in runtime.

Important Notes

The only exception is Nothing. Primarily because it requires Nothing to have a proper eigentype (Nothing.type) which would messed up a lot of existing logic for no obvious benefit (no more calling of foo=Nothing in parameters being one example).

Checklist

Please include the following checklist in your PR:

• The documentation has been updated if necessary.
• All code conforms to the
  Scala,
  Java,
  and
  Rust
  style guides.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed: Enso GUI was tested when built using BOTH
    ./run ide build and ./run ide watch.

[radeusgd]

The only exception is Nothing. Primarily because it requires Nothing to have a proper eigentype (Nothing.type) which would messed up a lot of existing logic for no obvious benefit (no more calling of foo=Nothing in parameters being one example).

I think we will have to face something like that at some point anyway, am I right @JaroslavTulach ? I think this is related to this Discord discussion where I notice that Truffle assertions do not allow Nothing to be a type (meta object) and a null value at the same time.

[JaroslavTulach]

The only exception is Nothing.
I think we will have to face something like that at some point anyway, am I right @JaroslavTulach ? I think this is related to this Discord discussion where I notice that Truffle assertions do not allow Nothing to be a type (meta object) and a null value at the same time.

Nothing is exceptional! #4074 provides special exceptions for Nothing to not have a meta-object.

[JaroslavTulach]

Except the doubts with "_static" suffix, I don't see any problem. Nice.

[hubertp]

I think we will have to face something like that at some point anyway, am I right @JaroslavTulach ? I think this is related to this Discord discussion where I notice that Truffle assertions do not allow Nothing to be a type (meta object) and a null value at the same time.

@radeusgd so you are OK with the PR? I'd rather keep the Nothing status as-is as changing it may potentially get out of hand. And this PR is blocking me on Array/Vector consolidation.

[radeusgd]

Looks good, I'd appreciate adding one more test to clarify how the statics work in an edge case which is unclear to me currently.

[radeusgd]

I get where this is coming from, but it is quite surprising. Should the Error argument be supported anymore?

Other than that - I'd like to see a test like

x = Error
x.to_text . should_equal "???"

What will this print? Will it be Error or a function now? Would be great to have a test documenting this behaviour, as it's non obvious.

[hubertp]

What will this print? Will it be Error or a function now?

The latter. OK, I will add case.

[radeusgd]

Hmm, is this definitely the way it is supposed to work? Shouldn't the static approach only work for static references to the types?

Anyway, even if not, I'm not suggesting to do anything about it in the current PR.
Thanks for adding the test, documenting the currently expected behaviour.

[hubertp]

I would even argue this now works as it should have worked to be begin with. Let's take further discussion offline.