Fix incorrect compile_to_assembly call args

[iamdefinitelyahuman]

The Issue

As discovered by @michwill and reported on Gitter, the following code was not compiling due to an assertion error:

@public    
def g():
    ok: bool = False
    for i in range(5):
        assert ok, "Reasons"

The issue was in vyper/compile_lll.py - several calls to compile_to_assembly were not including the existing_labels argument:

https://github.com/ethereum/vyper/blob/089d0c4046a5e71412b46205788a89e76d7646ea/vyper/compile_lll.py#L273-L275

What I did

Added existing_labels as an argument in compile_to_assembly calls where it was missing.

How to verify it

See the new test cases in tests/parser/features/test_assert.py. I also added checks for proper behavior of the iterated assertions.

Cute Animal Picture

[fubuloubu]

Would this have been caught with MyPy?

[iamdefinitelyahuman]

Would this have been caught with MyPy?

Probably - existing_labels is a set, break_dest is a tuple.

[charles-cooper]

Nice fix, thanks. While we're at it, could you please change the assertions to if <fail>: raise CompilerPanic('...')? Apparently some people run python with assertions turned off, plus the CompilerPanic has a more helpful error message.

[charles-cooper]

These two asserts could be CompilerPanic

https://github.com/ethereum/vyper/blob/d0d076cfd1503cd8c3bfada64b05ce206170bab3/vyper/compile_lll.py#L91-L95

[iamdefinitelyahuman]

@charles-cooper good call 👍 see new commit

[charles-cooper]

kind of a nitpick but to preserve the semantics I think these should be standalone if statements, not elif statements. Somebody could come in later and change the body of the previous branch to read withargs = [] and then we would no longer have the guarantee after this line that withargs is a dict.

[charles-cooper]

ditto

[charles-cooper]

LGTM, will merge once CI passes