Typechecks for default parameters and int arrays

[iamdefinitelyahuman]

What I did

• Fixed Default parameters do not get properly typechecked #1469
• Fixed Allow boolean as default parameter #1466 (comment)
• Added a type check for integer arrays, prior to this PR the following code would compile:

@public
def foo():
   a: uint256[2] = [-1, -1]

How I did it

• vyper/parser/parser_utils.py in make_setter, raise InvalidLiteralException when left type is BaseType and right value is out of bounds. This works for arrays as well because make_setter recursively calls itself until the left type is reduced to a BaseType.
• vyper/signatures/function_signature.py moved param check to validate_default_values to allow recursive calls for checking arrays

How to verify it

I added test cases for default parameters and array assignment.

Cute Animal Picture

[charles-cooper]

I like this code, but note that the method for typechecking is (slightly) different than the approach in ann_assign: https://github.com/ethereum/vyper/blob/ab39d4e9c5168eff2646dd29e23d7212654b636d/vyper/parser/stmt.py#L141-L151

I am good merging this so long as we add a note to this effect since we should reify the two code paths at some point.

[charles-cooper]

linking #764 (comment)

[iamdefinitelyahuman]

@charles-cooper I think some refactoring is possible so one of these checks isn't needed. It's late here, will have a look and hopefully push more tomorrow morning.

[iamdefinitelyahuman]

OK I take it back.. There are a lot of type checks happening in stmt._check_valid_assign, stmt.parse_return and parser_utils.make_setter that potentially overlap, and refactoring out the check in stmt._check_valid_assign that @charles-cooper pointed out only leads to more fragmented logic. This whole area should be refactored at some point but that's a big job. So going with the short-term fix and leaving a comment to the future refactor-er :)

[charles-cooper]

LGTM