Vyper: First phase reason string support

[jacqueswww]

This is the suggested template for new VIPs.

Preamble

VIP: 889
Title: First phase reason string support
Author: Jacques Wagener
Type: Standard Track
Status: Draft
Created: 2018-6-12
Requires (*optional): <VIP number(s)>
Replaces (*optional): <VIP number(s)>

Simple Summary

Revert opcode allows additional information to best sent on an assert, throw or overflow/clamp.
This VIP adds first phase support for the assert statement.

Abstract

Providing 2 values to the assert statement should allow user to write an error message.

Motivation

Following the discussions in https://github.com/ethereum/EIPs/issues/838. We can already produce compatible error statements, greatly enhancing the "tx-failed oh my expierence".

Specification

When supplying an assert error message

assert 1 != 2, "special error message"

Should produce, ABI function signature: Error(string).

https://github.com/ethereum/EIPs/issues/838#issuecomment-379238333

Backwards Compatibility

Since this a forwards feature and doesn't break any existing changes, this can be part

Copyright

Copyright and related rights waived via CC0

[ben-kaufman]

That’s a great feature but I don’t really like the syntax. I think of something like:

assert 1 < 2 else "special error message"

assert 1 < 2 catch "special error message"

What do you think?

_{Sent with GitHawk}

[jacqueswww]

I chose asset 1 < 2, "" because it follows python.

$ cat assert.py 
assert 1 == 2, "hello"

jacques at deadlock in ~
$ python assert.py 
Traceback (most recent call last):
  File "assert.py", line 1, in <module>
    assert 1 == 2, "hello"
AssertionError: hello

[jacqueswww]

Approved.

[jacqueswww]

Vyper side is done, busy investigating how I can add this to py-evm so the reason string can be retrieved.

[haydenadams]

@jacqueswww Sorry for even asking I know you're busy, but any chance this can be merged by ~Sept 1?

Uniswap (Vyper dex) needs a code freeze before formal verification. Would love to have error messages make the cut!

Not even going to ask about https://github.com/ethereum/vyper/issues/901 since theres no way lol

Edit: Potentially could be added in after verification has started, but would slow down the process.

[jacqueswww]

Sure thing, should be working with the newer eth tester which is what this was waiting for ;)
As for 901, I am making good progress. Have done all the basics so far. But yes Sept 1, might be a bit ... optimistic at stage. Let's see.

[fubuloubu]

@haydenadams you can add the strings now, it will parse (but not do anything).

Then when Jacques updates the parser to add support for generating this output, it can be regression tested versus the newest version of the compiler to see the version strings in action (and that it hasn't changed the code functionally).

Same goes to #901 actually. We have made the user-breaking changes already IIRC.

Technically... the codebase is still frozen.

[haydenadams]

@jacqueswww Awesome! Small changes like error messages might not be too bad to add after verification starts. #901 could be worth delaying the audit a week or two for gas/simplicity purposes, so let me know how progress goes!

@fubuloubu I also need to choose a Vyper commit to freeze on too!

[fubuloubu]

fair enough, it is probably better only to add the strings when the associated feature becomes available.

still, a regression against a newer version of a compiler (with small feature additions like reason strings) is much cheaper than a full first audit. you will probably go through several with your first version of code if you do any redeployments to fix bugs with usage. (p.s. you should have a plan for that if you don't already)

[haydenadams]

Yeah for sure, there will def be bug fixes/changes made during the process. Limited budget + deadline (hoping to launch ahead of Devcon4) so I'm trying to minimize them as much as possible!