Improve ergonomics of failing instruction assert and assert_vector

[jan-ferdinand]

When Triton VM tries to execute instruction assert while the top of its stack is unequal to 1, it fails. Currently, the error it returns does not give any further context. It would be beneficial for developers writing Triton assembly if instruction assert could be decorated with some context, indicating which of potentially many assert statements failed, and potentially also why it failed.

One idea would be to allow specifying an error code:

push 42
assert 127 ; Triton VM returns `InstructionError::AssertionFailed(127)`

Another possibility is to be more explicit about the failure reason:

push 42
assert [expect = "The moon should be blue."]

User-provided context should be optional. That is, the following program should remain syntactically correct (even though it will not halt successfully):

push 42
assert
halt

Note that all syntax examples are simply first drafts of suggestions and should be designed properly.

[aszepieniec]

Possible duplicate: #269

[Sword-Smith]

My main motivation for wanting this is fine-grained negative tests. In tasm-lib I have this test helper function.

Currently, I call the function like so

negative_test(
    &ShadowedAccessor::new(snippet),
    init_state.into(),
    &[InstructionError::AssertionFailed],
)

I'd like to be able to add a value to the AssertionFailed (and arguably VectorAssertionFailed too) such that the test can verify exactly where in the code the assert instruction is throwing.

[jan-ferdinand]

What are the additional design requirements from these raised points?

[jan-ferdinand]

Assertion error IDs are introduced in a987ebe with the following syntax:

assert error_id 42

Assertion error messages remain to be done.