Fix Runtime.assert

[Akirathan]

Fixes #8741

Pull Request Description

Simplifies implementation of Runtime.assert.

Important Notes

• Remove Runtime.assert_builtin builtin method, replace it with pure enso code and Runtime.assertions_enabled builtin.

Checklist

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

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

[Akirathan]

Without 798a882, the assertion error in

bar = assert (1 == 3) "Condition failed"
foo = bar
main = foo

is printed as:

Execution finished with an error: Assertion Error: 'Condition failed'
        at <enso> Panic.throw(Internal)
        at <enso> Runtime.assert<arg-2>(/home/pavel/dev/enso-2/built-distribution/enso-engine-0.0.1-dev-linux-amd64/enso-0.0.1-dev/lib/Standard/Base/0.0.1-dev/src/Runtime.enso:70-74)
        at <enso> Runtime.assert<arg-2>(/home/pavel/dev/enso-2/built-distribution/enso-engine-0.0.1-dev-linux-amd64/enso-0.0.1-dev/lib/Standard/Base/0.0.1-dev/src/Runtime.enso:69-74)
        at <enso> Runtime.assert(/home/pavel/dev/enso-2/built-distribution/enso-engine-0.0.1-dev-linux-amd64/enso-0.0.1-dev/lib/Standard/Base/0.0.1-dev/src/Runtime.enso:68-74)
        at <enso> tmp.bar(tmp.enso:12:5-38)
        at <enso> tmp.foo(tmp.enso:14:7-9)
        at <enso> tmp.main(tmp.enso:17:5-7)

With 798a882 the assertion error is printed as:

Execution finished with an error: Assertion Error: 'Condition failed'
        at <enso> tmp.bar(tmp.enso:12:5-38)
        at <enso> tmp.foo(tmp.enso:14:7-9)
        at <enso> tmp.main(tmp.enso:17:5-7)

As a user, I don't want to see internal Runtime.assert stack frames. I tried to create a special exception with dropped stack frames, but failed to do so. At the end, I have provided a special handling of Assertion_Error printing in 798a882. You are welcome to provide better suggestions.

[JaroslavTulach]

There is InteropLibrary.getExceptionStackTrace method. You might find it useful. I used it in DataflowError speedup.

[radeusgd]

I don't think such a very specific hack (including logic for just one specific type of exception) is a good idea at all just to remove 4 frames from a specific stack trace.

Is it really such a problem that the stack trace contains additional 4 frames? The assertions are an advanced feature anyway, a user advanced enough to inspect stack traces will quickly see which frames are relevant to their problem.

I think there may be other places as well where we throw the panic from a helper and so it contains frames of that helper. Is it really a problem?

Moreover the hack only applies in one place, ignoring all the other places where we are manipulating stack traces - so the printed stack trace will be inconsistent depending on where we get it from.

[Akirathan]

There is InteropLibrary.getExceptionStackTrace method. You might find it useful. I used it in DataflowError speedup.

@JaroslavTulach Unfortunately no. getExceptionStackTrace is an interop message, which is, unfortunatelly, not used by PolyglotException.getPolyglotStackTrace that we call in our runner's Main.scala

So let's just remove the ugly workaround, and live with a slightly longer stack traces for asserts.

[Akirathan]

@radeusgd Just to be sure, I have looked into the Graal graphs by running enso --no-ir-caches --dump-graphs --run tmp.enso (and ensuring assertions are disabled) on:

from Standard.Base import all
import Standard.Base.Runtime.State
from Standard.Base.Runtime import assert

main =
    res = 1.up_to 10000 . map i->
        assert (i == i)
    res.first

And I can confirm that Truffle+Graal compiles assert into just 4 LoadField instructions, which is what I have expected.

[Akirathan]

It appears that I have accidentally used the assert wrongly, so the bug report #8741 might be invalid. But as this PR simplifies the implementation of Runtime.assert and I have even made sure that Runtime.assert is, in fact, a nop in production after PE (See my previous comment), I am merging this PR.