internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: vyperlang/vyper

Issue:
KeyError when using an absolute file name
### Version Information

* vyper version: 0.1.0b15
* OS: Linux, MacOS
* Python version: 3.7

### What's your issue about?

Since 0.1.0.b15 using an absolute filename when calling Vyper from the command line 
```$ vyper /home/.../mycontract.vy```
 causes a KeyError.



Discussion:
Why are there 3 dots?
Oh sorry,  I just used them as a replacement for my actual path. I meant something like this
```$ vyper /home/me/myproject/mycontract.vy```
Gotcha, haha. Yes, this seems like a bug. I wonder why...
It only happens for me if the file is in some subdirectory of my current directory. If I change the root path to something else it works.
And this was working before `b15`?
Yes.
The issue comes from 7902d9ff0df71f30b2293de18050f9dc5dd26f84 - sorry about that!  Working on a fix now.

Resolving patch:
diff --git a/vyper/cli/vyper_compile.py b/vyper/cli/vyper_compile.py
--- a/vyper/cli/vyper_compile.py
+++ b/vyper/cli/vyper_compile.py
@@ -132,8 +132,8 @@ def _parse_args(argv):
         print(json.dumps(compiled))
         return
 
-    for key in args.input_files:
-        for data in compiled[key].values():
+    for contract_data in compiled.values():
+        for data in contract_data.values():
             if isinstance(data, (list, dict)):
                 print(json.dumps(data))
             else:


Test patch:
diff --git a/tests/cli/vyper_compile/test_parse_args.py b/tests/cli/vyper_compile/test_parse_args.py
new file mode 100644
--- /dev/null
+++ b/tests/cli/vyper_compile/test_parse_args.py
@@ -0,0 +1,29 @@
+import os
+
+import pytest
+
+from vyper.cli.vyper_compile import (
+    _parse_args,
+)
+
+
+@pytest.fixture
+def chdir_path(tmp_path):
+    orig_path = os.getcwd()
+    yield tmp_path
+    os.chdir(orig_path)
+
+
+def test_paths(chdir_path):
+    code = """
+@public
+def foo() -> bool:
+    return True
+"""
+    bar_path = chdir_path.joinpath('bar.vy')
+    with bar_path.open('w') as fp:
+        fp.write(code)
+    _parse_args([str(bar_path)])  # absolute path
+    os.chdir(chdir_path.parent)
+    _parse_args([str(bar_path)])  # absolute path, subfolder of cwd
+    _parse_args([str(bar_path.relative_to(chdir_path.parent))])  # relative path
Repository: vyperlang/vyper

Issue:
Weird issue with returning data
### Version Information

* vyper Version (output of `vyper --version`): 0.1.0b15
* OS: linux
* Python Version (output of `python --version`): 3.7.5

### What's your issue about?
contract:
```python
from vyper.interfaces import ERC721 
 
@public 
def foo(): 
    success: bool = ERC721(msg.sender).transferFrom(msg.sender, self, 1) 
```

error:
```bash
vyper/parser/stmt.py in _check_valid_assign(self, sub)
    140                 )
    141         # Check that the integer literal, can be assigned to uint256 if necessary.
--> 142         elif (self.stmt.annotation.id, sub.typ.typ) == ('uint256', 'int128') and sub.typ.is_literal:
    143             if not SizeLimits.in_bounds('uint256', sub.value):
    144                 raise InvalidLiteralException(

AttributeError: 'NoneType' object has no attribute 'typ'
```


### How can it be fixed?
Unsure where this comes from, but if I remove `success: bool =` from the equation it goes away


Discussion:
I think, this is the same deal as https://github.com/vyperlang/vyper/issues/1823. `transferFrom` doesn't actually return anything.
Yeah, it shouldn't compile but the error message is off

Resolving patch:
diff --git a/vyper/parser/stmt.py b/vyper/parser/stmt.py
--- a/vyper/parser/stmt.py
+++ b/vyper/parser/stmt.py
@@ -132,6 +132,11 @@ def _check_valid_assign(self, sub):
                     f'Invalid type, expected: {self.stmt.annotation.value.id},'
                     f' got: {sub.typ}', self.stmt
                 )
+        elif sub.typ is None:
+            # Check that the object to be assigned is not of NoneType
+            raise TypeMismatch(
+                f"Invalid type, expected {self.stmt.annotation.id}", self.stmt
+            )
         elif isinstance(sub.typ, StructType):
             # This needs to get more sophisticated in the presence of
             # foreign structs.


Test patch:
diff --git a/tests/parser/features/test_assignment.py b/tests/parser/features/test_assignment.py
--- a/tests/parser/features/test_assignment.py
+++ b/tests/parser/features/test_assignment.py
@@ -260,3 +260,18 @@ def foo():
             lambda: get_contract_with_gas_estimation(contract),
             TypeMismatch
         )
+
+
+def test_invalid_nonetype_assignment(assert_compile_failed, get_contract_with_gas_estimation):
+    code = """
+@private
+def bar():
+    pass
+
+@public
+def foo():
+    ret : bool = self.bar()
+"""
+    assert_compile_failed(
+        lambda: get_contract_with_gas_estimation(code), TypeMismatch
+    )
Repository: vyperlang/vyper

Issue:
Error strings are zero-padded to 32 bytes
### What's your issue about?
Vyper zero-pads error strings to 32 bytes within the bytecode. This in turn causes the string to occupy an additional memory slot, and can lead to [decoding weirdness](https://etherscan.io/tx/0xa0f0aa5fc4f56771a0b49ff66c752bcad2a32844ec4b173337086d6610571d65).

Here is an example contract:

```python
@public
def foo():
    raise "foo"
```

Here is the bytecode that handles the error string:

```python
PUSH4 0x8C379A0   # error string signature
PUSH2 0x140
MSTORE
PUSH1 0x20
PUSH2 0x160
MSTORE
PUSH1 0x3
PUSH2 0x180
MSTORE
PUSH32 0x666F6F00000000000000000000000000000  # "foo" with many trailing zeros
PUSH2 0x1A0
MSTORE 
PUSH2 0x180
POP
PUSH1 0x0
PUSH2 0x15
JUMPI
PUSH1 0x84  # returns 4 memory slots
PUSH2 0x15C
REVERT
```

### How can it be fixed?
Remove the zero-padding and use `PUSH[n]` where `n` is the actual length of the encoded string. This way we can also reduce the size in memory that we are returning.



Discussion:

Resolving patch:
diff --git a/vyper/parser/stmt.py b/vyper/parser/stmt.py
--- a/vyper/parser/stmt.py
+++ b/vyper/parser/stmt.py
@@ -399,7 +399,7 @@ def _assert_reason(self, test_expr, msg):
                     'assert_reason',
                     test_expr,
                     int(sig_placeholder + 28),
-                    int(4 + 32 + get_size_of_type(reason_str_type) * 32),
+                    int(4 + get_size_of_type(reason_str_type) * 32),
                     ],
                 ]
         return LLLnode.from_list(assert_reason, typ=None, pos=getpos(self.stmt))


Test patch:
diff --git a/tests/parser/features/test_assert.py b/tests/parser/features/test_assert.py
--- a/tests/parser/features/test_assert.py
+++ b/tests/parser/features/test_assert.py
@@ -1,4 +1,5 @@
 import pytest
+from eth_abi import decode_single
 from eth_tester.exceptions import TransactionFailed
 
 from vyper.exceptions import ConstancyViolation, StructureException
@@ -192,3 +193,20 @@ def test(x: uint256[3]) -> bool:
     assert_tx_failed(lambda: c.test([5, 1, 3]))
     assert_tx_failed(lambda: c.test([1, 5, 3]))
     assert_tx_failed(lambda: c.test([1, 3, 5]))
+
+
+def test_assest_reason_revert_length(w3, get_contract):
+    code = """
+@public
+def test() -> int128:
+    assert 1 == 2, "oops"
+    return 1
+"""
+    c = get_contract(code)
+    w3.manager.provider.ethereum_tester.backend.is_eip838_error = lambda err: False
+    with pytest.raises(TransactionFailed) as e_info:
+        c.test()
+    error_bytes = eval(e_info.value.args[0])
+    assert len(error_bytes) == 100
+    msg = decode_single('string', error_bytes[36:])
+    assert msg == 'oops'
Repository: vyperlang/vyper

Issue:
VIP: Use uint256 for public array getters
## Simple Summary
When an array is declared public, the generated getter should accept `uint256` instead of `int128` in order to handle the lookups.

## Motivation
We do not allow array lookups with negative numbers, so the use of `int128` is unintuitive.

## Specification
As an example, the following variable:

```python
foo: public(address[3])
```

Should produce a getter with the following signature:

```python
def foo(arg0: uint256) -> address: constant
```

## Backwards Compatibility
This is not a breaking change, but it does amount to a deviation in expected behavior.

## Dependencies
Not dependent, but related to #1979 

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/)



Discussion:
It actually is a breaking change, because it changes the Method ID of the getter function. I think this is a good thing though, as it will match the Solidity implementation.
Ahh, I forgot about interfaces we generate from other contracts.  Was thinking it wasn't breaking since it would only affect newly compiled contracts. Good call.

Resolving patch:
diff --git a/vyper/parser/global_context.py b/vyper/parser/global_context.py
--- a/vyper/parser/global_context.py
+++ b/vyper/parser/global_context.py
@@ -197,7 +197,7 @@ def _mk_getter_helper(cls, typ, depth=0):
             o = []
             for funname, head, tail, base in cls._mk_getter_helper(typ.subtype, depth + 1):
                 o.append(
-                    (funname, (f"arg{depth}: int128, ") + head, (f"[arg{depth}]") + tail, base,)
+                    (funname, (f"arg{depth}: uint256, ") + head, (f"[arg{depth}]") + tail, base,)
                 )
             return o
         # Mapping type: do not extend the getter name, add an input argument for


Test patch:
Repository: vyperlang/vyper

Issue:
In comparator fails when array is in calldata
### Version Information

* vyper Version : `0.1.0b17`
* OS: linux
* Python Version : `3.8.0`

### What's your issue about?

Use of the `in` comparator fails when the array being checked is located in calldata:

```python
@public
def foo(a: int128, b: int128[1]) -> bool:
    return a in b
```

```python
>>> contract.foo(1, [1])
False  # should be True!
```

* the comparison works as expected if the array is a constant, literal, memory or storage variable
* changing the location of the left-hand value has no effect
* changing the data type has no effect
* changing the length of the array has no effect

### How can it be fixed?
Unclear to me at this time, likely an issue in the `build_in_comparator` method of `vyper/parser/expr.py`.


Discussion:

Resolving patch:
diff --git a/vyper/parser/expr.py b/vyper/parser/expr.py
--- a/vyper/parser/expr.py
+++ b/vyper/parser/expr.py
@@ -493,8 +493,9 @@ def build_in_comparator(self):
                 ["add", ["sha3_32", right], ["mload", MemoryPositions.FREE_LOOP_INDEX]],
             ]
         else:
+            load_operation = "mload" if right.location == "memory" else "calldataload"
             load_i_from_list = [
-                "mload",
+                load_operation,
                 ["add", right, ["mul", 32, ["mload", MemoryPositions.FREE_LOOP_INDEX]]],
             ]
 


Test patch:
diff --git a/tests/parser/features/iteration/test_range_in.py b/tests/parser/features/iteration/test_range_in.py
--- a/tests/parser/features/iteration/test_range_in.py
+++ b/tests/parser/features/iteration/test_range_in.py
@@ -44,6 +44,24 @@ def in_test(x: int128) -> bool:
     assert c.in_test(32000) is False
 
 
+def test_in_calldata_list(get_contract_with_gas_estimation):
+    code = """
+@public
+def in_test(x: int128, y: int128[10]) -> bool:
+    if x in y:
+        return True
+    return False
+    """
+
+    c = get_contract_with_gas_estimation(code)
+
+    assert c.in_test(1, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) is True
+    assert c.in_test(9, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) is True
+    assert c.in_test(11, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) is False
+    assert c.in_test(-1, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) is False
+    assert c.in_test(32000, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) is False
+
+
 def test_cmp_in_list(get_contract_with_gas_estimation):
     code = """
 @public
Repository: vyperlang/vyper

Issue:
Arrays as default arguments do not properly copy to memory
### Version Information

* vyper Version: latest master
* OS: linux
* Python Version: 3.8.2

### What's your issue about?
When an array used as a default argument is copied to a memory variable, every item in the memory variable has the value of the first item in the array. For example:

```python
@public
@constant
def foo(a: int128[2] = [1, 2]) -> int128[2]:
    b: int128[2] = a
    return b
```

Calls to `foo` produce the following output:

```python
>>> x.foo()
(1, 1)
>>> x.foo([4, 6])
(4, 4)
```

* The same effect is observed with longer arrays and different types.
* Returning directly from calldata gives the expected result.
* Writing to storage gives the expected result.



Discussion:

Resolving patch:
diff --git a/vyper/parser/function_definitions/parse_external_function.py b/vyper/parser/function_definitions/parse_external_function.py
--- a/vyper/parser/function_definitions/parse_external_function.py
+++ b/vyper/parser/function_definitions/parse_external_function.py
@@ -106,7 +106,8 @@ def parse_external_function(
                     arg.name, MemoryPositions.RESERVED_MEMORY + arg.pos, arg.typ, False,
                 )
             elif i >= default_args_start_pos:  # default args need to be allocated in memory.
-                default_arg_pos, _ = context.memory_allocator.increase_memory(32)
+                type_size = get_size_of_type(arg.typ) * 32
+                default_arg_pos, _ = context.memory_allocator.increase_memory(type_size)
                 context.vars[arg.name] = VariableRecord(
                     name=arg.name, pos=default_arg_pos, typ=arg.typ, mutable=False,
                 )


Test patch:
diff --git a/tests/parser/functions/test_default_parameters.py b/tests/parser/functions/test_default_parameters.py
--- a/tests/parser/functions/test_default_parameters.py
+++ b/tests/parser/functions/test_default_parameters.py
@@ -111,6 +111,45 @@ def fooBar(a: bytes[100], b: uint256[2], c: bytes[6] = b"hello", d: int128[3] =
     assert c.fooBar(b"booo", [55, 66]) == [b"booo", 66, c_default, d_default]
 
 
+def test_default_param_internal_function(get_contract):
+    code = """
+@internal
+@view
+def _foo(a: int128[3] = [1, 2, 3]) -> int128[3]:
+    b: int128[3] = a
+    return b
+
+
+@external
+@view
+def foo() -> int128[3]:
+    return self._foo([4, 5, 6])
+
+@external
+@view
+def foo2() -> int128[3]:
+    return self._foo()
+    """
+    c = get_contract(code)
+
+    assert c.foo() == [4, 5, 6]
+    assert c.foo2() == [1, 2, 3]
+
+
+def test_default_param_external_function(get_contract):
+    code = """
+@external
+@view
+def foo(a: int128[3] = [1, 2, 3]) -> int128[3]:
+    b: int128[3] = a
+    return b
+    """
+    c = get_contract(code)
+
+    assert c.foo([4, 5, 6]) == [4, 5, 6]
+    assert c.foo() == [1, 2, 3]
+
+
 def test_default_param_clamp(get_contract, monkeypatch, assert_tx_failed):
     code = """
 @external
Repository: vyperlang/vyper

Issue:
Documentation Updates Megaissue
While working on #1915 I've run into some areas where the documentation is lacking. This issue is a list of topics that I think need work.  It may change over time.

- [x] `public` and `constant` as methods applied to storage variables
- [x] `self`
- [x] assignment
- [x] statements, expressions, control structure
- [x] scoping rules
- [x] `for` loops
- [x] tuples
- [x] contract objects
- [ ] memory layout of data types
- [ ] pass-by-reference / pass-by-value
- [ ] abi format
- [x] arithmetic functions (should be moved from types to builtin functions)
- [x] allowable literals for each type
- [x] examples for each of the builtin functions
- [x] `__init__` method


Discussion:

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -49,11 +49,10 @@
 # The suffix(es) of source filenames.
 # You can specify multiple suffix as a list of string:
 #
-# source_suffix = ['.rst', '.md']
-source_suffix = ".rst"
+source_suffix = [".rst", ".md"]
 
 # The master toctree document.
-master_doc = "index"
+master_doc = "toctree"
 
 # General information about the project.
 project = "Vyper"
@@ -110,6 +109,8 @@
 
 html_js_files = ["js/toggle.js"]
 
+html_logo = "vyper-logo-transparent.svg"
+
 # Custom sidebar templates, must be a dictionary that maps document names
 # to template names.
 #
@@ -129,7 +130,7 @@
 
 # -- Options for LaTeX output ---------------------------------------------
 
-latex_elements = {
+latex_elements: dict = {
     # The paper size ('letterpaper' or 'a4paper').
     #
     # 'papersize': 'letterpaper',
@@ -186,8 +187,6 @@
     ".md": CommonMarkParser,
 }
 
-source_suffix = [".rst", ".md"]
-
 intersphinx_mapping = {
     "brownie": ("https://eth-brownie.readthedocs.io/en/stable", None),
     "pytest": ("https://docs.pytest.org/en/latest/", None),


Test patch:
Repository: vyperlang/vyper

Issue:
Raising to a negative number raises CompilerPanic
### Version Information
vyper Version (output of `vyper --version`): 0.1.0b17

### What's your issue about?
Trying to compile this:
```python
@public
def foo() -> decimal:
    return 10 ** (-3)  # 0.001
```
raises this `CompilerPanic`:
```
CompilerPanic: Invalid value for LLL AST node: 0.001 Please create an issue.
```

### How can it be fixed?
Should raise on trying to do a power to a negative number.

Side note: we should probably disallow negative integers from this operation, at least until we allow decimals as operands (probably after #1807 is introduced too)



Discussion:

Resolving patch:
diff --git a/vyper/ast/nodes.py b/vyper/ast/nodes.py
--- a/vyper/ast/nodes.py
+++ b/vyper/ast/nodes.py
@@ -7,6 +7,7 @@
 from vyper.exceptions import (
     CompilerPanic,
     InvalidLiteral,
+    InvalidOperation,
     OverflowException,
     SyntaxException,
     TypeMismatch,
@@ -910,6 +911,8 @@ class Pow(VyperNode):
     def _op(self, left, right):
         if isinstance(left, decimal.Decimal):
             raise TypeMismatch("Cannot perform exponentiation on decimal values.", self._parent)
+        if right < 0:
+            raise InvalidOperation("Cannot calculate a negative power", self._parent)
         return int(left ** right)
 
 


Test patch:
Repository: vyperlang/vyper

Issue:
Error messages with struct display all members
### Version Information
* vyper Version (output of `vyper --version`): 0.2.3
* OS: linux
* Python Version (output of `python --version`): 3.8.5

### What's your issue about?
Trying to use a Struct in an unsupported way:
```python
struct Message: 
    sender: address 
    recipient: address 
    amount: uint256
     
@external 
def processMetaBatch(messages: Message[20]) -> bool: 
    return True 
```
yields weird error messages: 
```python
InvalidType: List of struct Message: {sender: address, recipient: address, amount: uint256}s not allowed
```

### How can it be fixed?
Make it display just:
```python
InvalidType: List of struct Message not allowed
```
NOTE: Also remove the `s` from the end, as that might not always be correct


Discussion:

Resolving patch:
diff --git a/vyper/types/types.py b/vyper/types/types.py
--- a/vyper/types/types.py
+++ b/vyper/types/types.py
@@ -126,8 +126,13 @@ def eq(self, other):
         return other.name == self.name and other.members == self.members
 
     def __repr__(self):
-        prefix = "struct " + self.name + ": " if self.name else ""
-        return prefix + "{" + ", ".join([k + ": " + repr(v) for k, v in self.members.items()]) + "}"
+        if self.name:
+            return "struct " + self.name
+        else:
+            # Anonymous struct
+            return (
+                "struct {" + ", ".join([k + ": " + repr(v) for k, v in self.members.items()]) + "}"
+            )
 
     def tuple_items(self):
         return list(self.members.items())
@@ -158,7 +163,7 @@ def canonicalize_type(t, is_indexed=False):
 
     if isinstance(t, ListType):
         if not isinstance(t.subtype, (ListType, BaseType)):
-            raise InvalidType(f"List of {t.subtype}s not allowed")
+            raise InvalidType(f"List of {t.subtype} not allowed")
         return canonicalize_type(t.subtype) + f"[{t.count}]"
 
     if isinstance(t, TupleLike):


Test patch:
Repository: vyperlang/vyper

Issue:
Bad exception message when using attribute in AnnAssign

### What's your issue about?
The following code:

```python
struct Foo:
    a: uint256

@external
def test():
    foo: Foo = empty(Foo)
    foo.a: uint256 = 123
```

produces the following exception:

```python
File "/home/computer/code/python/vyper/vyper/context/validation/local.py", line 178, in visit_AnnAssign
    name = node.target.id
AttributeError: 'Attribute' object has no attribute 'id'
```

It is correct that this should not compile, but the raised exception is not useful.


### How can it be fixed?
In `vyper.context.validation.local`, add logic to correctly handle an `AnnAssign` where the left-hand side is an `Attribute` node.



Discussion:

Resolving patch:
diff --git a/vyper/context/validation/local.py b/vyper/context/validation/local.py
--- a/vyper/context/validation/local.py
+++ b/vyper/context/validation/local.py
@@ -170,6 +170,10 @@ def __init__(
                 )
 
     def visit_AnnAssign(self, node):
+        name = node.get("target.id")
+        if name is None:
+            raise VariableDeclarationException("Invalid assignment", node)
+
         if not node.value:
             raise VariableDeclarationException(
                 "Memory variables must be declared with an initial value", node
@@ -179,7 +183,7 @@ def visit_AnnAssign(self, node):
         validate_expected_type(node.value, type_definition)
 
         try:
-            self.namespace[node.target.id] = type_definition
+            self.namespace[name] = type_definition
         except VyperException as exc:
             raise exc.with_annotation(node) from None
 


Test patch:
diff --git a/tests/parser/exceptions/test_variable_declaration_exception.py b/tests/parser/exceptions/test_variable_declaration_exception.py
--- a/tests/parser/exceptions/test_variable_declaration_exception.py
+++ b/tests/parser/exceptions/test_variable_declaration_exception.py
@@ -33,6 +33,14 @@ def foo() -> int128:
     x: int128
 s: S = S()
     """,
+    """
+foo.a: int128
+    """,
+    """
+@external
+def foo():
+    bar.x: int128 = 0
+    """,
 ]