Include the constant name for assert error messages

[hackaugusto]

We are using assert.err=<code> to give context for a given error. <code> may be a integer or a constant, a failing assert like assert.err=ERR_INVALID_NOTE_TYPE will then result in an error similar to:

ExecuteTransactionProgramFailed(FailedAssertion { clk: 10244, err_code: 131140, err_msg: None })

There are a few issues with the above:

• We are defining the constants using hex, and not integer, so looking for 131140 in the code base will give no results
• The number of prefixed zeros in the hex string is variable, so looking for 0x20044 may not give a hit, for the example above the value was defined as 0x00020044

The above makes it unnecessarily convoluted to find the corresponding error. A simple fix for this is to add the string <code> in the error message. So the error above would be:

ExecuteTransactionProgramFailed(FailedAssertion { clk: 10244, err_code: 131140, err: "ERR_INVALID_NOTE_TYPE" err_msg: None })

If defined with a hex directly, i.e. assert.err=0x00020044:

ExecuteTransactionProgramFailed(FailedAssertion { clk: 10244, err_code: 131140, err: "0x00020044" err_msg: None })

And if defined with a number, i.e. assert.err=131140:

ExecuteTransactionProgramFailed(FailedAssertion { clk: 10244, err_code: 131140, err: "131140" err_msg: None })

[bitwalker]

I think this would be better solved by having proper source-level debug information associated with a program, which I think should be a pretty high priority in general because of how critical it is to user experience (and for us, in terms of efficient troubleshooting/debugging). To implement this as requested, we'd need to implement the same kind of auxiliary structure as would be needed for debug info anyway, so I see it as essentially the same amount of effort involved.

Source-level debug info also works equally well for code generated by the compiler. The vast majority of our users are more than likely going to be working in a higher-level language, not MASM, so we want to be able to emit errors/diagnostics that speak in terms the user understands. By using source spans, we can show the snippet of code associated with a particular error in whatever language it was actually written (assuming a program was distributed with debug info), whereas an error specific to MASM/MAST is not going to be particularly helpful.

I've been wanting to write up a proposal for debug info, but haven't been able to get to it, but this is a reminder to do that sooner rather than later I think.