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

Issue:
Missing error message for type mismatch inside a built-in type (min/max).
### Version Information

* `vyper Version (output of `vyper --version`): 0.3.1+commit.2bf43eee and later up to 0.3.3`
* `OS: Linux squire 5.14.0-4mx-amd64 #1 SMP Debian 5.14.16-1~mx21+1 (2021-11-05) x86_64 GNU/Linux`
* `Python 3.9.2`

### What's your issue about?
Compiler dies with weird/broken error message and no line number information to help identify where it broke.

```
$ brownie test tests/test_auction.py 
Brownie v1.18.1 - Python development framework for Ethereum

Compiling contracts...
  Vyper version: 0.3.1+commit.2bf43eee
Unhandled exception in 'contracts/auction.vy':
TypeMismatch: Error Message not found.


ERROR: Unable to load project
```

happens if you try to compile the following:
```
$ cat vyper-error.vy 
# @version 0.3.1

@external 
def broken():
    a : uint256 = 3
    b : int128 = 4

    # Error occurs because of b's type is inconsistent with a & c.
    # This code works :
    # c : uint256 = (min(a, convert(b, uint256))+1)/2
    c : uint256 = (min(a, b)+1)/2

```

Appears to be a problem figuring out the right error to report when in the context of the min or max functions. Possibly all built-in's but haven't tried the rest.



Discussion:
related to this: #2788

Resolving patch:
diff --git a/vyper/builtin_functions/functions.py b/vyper/builtin_functions/functions.py
--- a/vyper/builtin_functions/functions.py
+++ b/vyper/builtin_functions/functions.py
@@ -1742,7 +1742,7 @@ def fetch_call_return(self, node):
             *node.args, filter_fn=lambda x: isinstance(x, NumericAbstractType)
         )
         if not types_list:
-            raise TypeMismatch
+            raise TypeMismatch("Cannot perform action between dislike numeric types", node)
 
         return types_list.pop()
 


Test patch:
Repository: vyperlang/vyper

Issue:
accessing codesize on struct member throws AttributeError: 'Attribute' object has no attribute 'id'
### Version Information

* vyper Version (output of `vyper --version`): 0.3.3
* OS: osx
* Python Version (output of `python --version`): Python 3.8.2

### What's your issue about?

Please include information like:

* full output of the error you received
```AttributeError: 'Attribute' object has no attribute 'id'AttributeError: 'Attribute' object has no attribute 'id'```
* what command you ran ```vyper contract.vy```
* the code that caused the failure:

```# @version 0.3.3

struct ConduitBatch1155Transfer:
    token: address
    _from: address
    to: address
    ids: DynArray[uint256, 10] 
    amounts: DynArray[uint256, 10] 

SAFEBATCHTRANSFERFROM_MID: constant(Bytes[4]) = method_id("safeBatchTransferFrom(address,address,uint256[],uint256[],bytes)")

@internal
def _performERC1155BatchTransfers(batchTransfers: DynArray[ConduitBatch1155Transfer, 10]):
    for transfer in batchTransfers:
        assert transfer.token.codesize != 0
        _response: Bytes[32] = raw_call(
        transfer.token,
        _abi_encode(
            SAFEBATCHTRANSFERFROM_MID,
            transfer._from,
            transfer.to,
            transfer.ids,
            transfer.amounts
            ),
            max_outsize=32
        ) 
        if len(_response) > 0:
            assert convert(_response, bool), "SafeBatchTransferFrom failed" ```
            





Discussion:
minimal repro:
```vyper
struct Foo:
    t: address
foo: Foo

@external
def bar() -> uint256:
    return self.foo.t.codesize
```

Resolving patch:
diff --git a/vyper/codegen/expr.py b/vyper/codegen/expr.py
--- a/vyper/codegen/expr.py
+++ b/vyper/codegen/expr.py
@@ -334,7 +334,7 @@ def parse_Attribute(self):
             addr = Expr.parse_value_expr(self.expr.value, self.context)
             if is_base_type(addr.typ, "address"):
                 if self.expr.attr == "codesize":
-                    if self.expr.value.id == "self":
+                    if self.expr.get("value.id") == "self":
                         eval_code = ["codesize"]
                     else:
                         eval_code = ["extcodesize", addr]


Test patch:
diff --git a/tests/parser/syntax/test_code_size.py b/tests/parser/syntax/test_code_size.py
--- a/tests/parser/syntax/test_code_size.py
+++ b/tests/parser/syntax/test_code_size.py
@@ -32,6 +32,15 @@ def foo() -> uint256:
 def foo() -> uint256:
     return self.codesize
     """,
+    """
+struct Foo:
+    t: address
+foo: Foo
+
+@external
+def bar() -> uint256:
+    return self.foo.t.codesize
+    """,
 ]
Repository: vyperlang/vyper

Issue:
Missing @view decorator for interface ERC20Detailed.py
### Version Information
* vyper Version (output of `vyper --version`): 0.3.3
* OS: linux
* Python Version (output of `python --version`): Python 3.9.5
### What's your issue about?
**Issue**
Error using `ERC20Detailed.py` as an interface to a vyper class. Trying to compile the following snippet produces the following error.
```
# @version 0.3.3

from vyper.interfaces import ERC20Detailed

@view
@external
def getSymbol() -> String[32]:
    return ERC20Detailed(0x5f3b5DfEb7B28CDbD7FAba78963EE202a494e2A2).symbol()
```
**Error**
```
vyper.exceptions.StateAccessViolation: May not call state modifying function 'symbol' within a constant
function.vyper.exceptions.StateAccessViolation: May not call state modifying function 'symbol' within a constant function.
```
**Reason**
This issue occurs because `ERC20Detailed.py` does not contain `@view` decorator for its interfaces
### How can it be fixed?
Adding `@view` decorator to interface under `vyper.builtin_interfaces.ERC20Detailed.py`
```
@external
@view
def name() -> String[1]:
    pass
    
@external
@view
def symbol() -> String[1]:
    pass
    
@external
@view
def decimals() -> uint8:
    pass
```
**Why?**
Running `vyper -f interface examples/tokens/ERC20.vy` generates the following
```
...
@view
@external
def name() -> String[32]:
    pass
    
@view
@external
def symbol() -> String[32]:
    pass
    
@view
@external
def decimals() -> uint8:
    pass
...
```

Adding `@view` decorator to `vyper.builtin_interfaces.ERC20Detailed.py` would make interface consistent.


Discussion:

Resolving patch:
diff --git a/vyper/builtin_interfaces/ERC20Detailed.py b/vyper/builtin_interfaces/ERC20Detailed.py
--- a/vyper/builtin_interfaces/ERC20Detailed.py
+++ b/vyper/builtin_interfaces/ERC20Detailed.py
@@ -5,14 +5,17 @@
 """
 
 interface_code = """
+@view
 @external
 def name() -> String[1]:
     pass
 
+@view
 @external
 def symbol() -> String[1]:
     pass
 
+@view
 @external
 def decimals() -> uint8:
     pass


Test patch:
Repository: vyperlang/vyper

Issue:
CBOR section at end should include length indicator like in Solidity
## Simple Summary

PR #2860 introduced a CBOR section at the end of Vyper bytecode, like Solidity has.  However, unlike in Solidity, there's nothing to indicate the length of this CBOR section.  While it's easy enough to recognize the fixed format used in 0.3.4 (since it always has a length of 11 and only the last 3 bytes vary), if this format changes so that the length changes, bytecode disassemblers and analzyers will need to know about every possible format used in order to determine where the CBOR starts.

As such, like in Solidity, the CBOR section should be followed by a length indicator so we can determine the demarcation between the code and the CBOR.

## Motivation

Covered above.

## Specification

Depends on how you want to do it!  If you want to mimic Solidity exactly, the CBOR section would be followed by a 2-byte big-endian number representing the length of the CBOR section (the length does not include the 2 bytes itself).  But any way works so long as it's reliably locatable.

## Backwards Compatibility

There should be no substantial backwards incompatibility.  If any bytecode disassemblers or analyzers are accounting for the old format, they'll need to account for the new format as well, but the old format is already absent prior to 0.3.4, so...

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/)


Discussion:

Resolving patch:
diff --git a/vyper/ir/compile_ir.py b/vyper/ir/compile_ir.py
--- a/vyper/ir/compile_ir.py
+++ b/vyper/ir/compile_ir.py
@@ -994,6 +994,7 @@ def assembly_to_evm(assembly, pc_ofst=0, insert_vyper_signature=False):
     if insert_vyper_signature:
         # CBOR encoded: {"vyper": [major,minor,patch]}
         bytecode_suffix += b"\xa1\x65vyper\x83" + bytes(list(version_tuple))
+        bytecode_suffix += len(bytecode_suffix).to_bytes(2, "big")
 
     CODE_OFST_SIZE = 2  # size of a PUSH instruction for a code symbol
 


Test patch:
Repository: vyperlang/vyper

Issue:
Option to disable metadata seemingly not available with JSON input
## Simple Summary

Vyper 0.3.7 added an option to disable metadata in bytecode.  However, this option seems to only be available as a command-line flag, and not via JSON input.  (If it is available via the latter, it's not documented.)  This option should be available via JSON input, or, if it already is, it should be documented in the "Compiling a Contract" page.

## Motivation

All compilation options that affect the bytecode output should be available via JSON input so that programs that need to invoke the compiler on specified text sources have access to all compilation options.

(E.g., in Truffle, we often download sources from Etherscan or Sourcify and then compile them, and it's important that we use exactly the same settings that were used to compile them originally; if we can't do this via the JSON input, we have a problem.  Mind you, we don't yet do this for Vyper, but we're intending to eventually!)

## Backwards Compatibility

There should be no issues with backwards compatibility.


Discussion:

Resolving patch:
diff --git a/vyper/cli/vyper_json.py b/vyper/cli/vyper_json.py
--- a/vyper/cli/vyper_json.py
+++ b/vyper/cli/vyper_json.py
@@ -354,6 +354,7 @@ def compile_from_input_dict(
 
     evm_version = get_evm_version(input_dict)
     no_optimize = not input_dict["settings"].get("optimize", True)
+    no_bytecode_metadata = not input_dict["settings"].get("bytecodeMetadata", True)
 
     contract_sources: ContractCodes = get_input_dict_contracts(input_dict)
     interface_sources = get_input_dict_interfaces(input_dict)
@@ -377,6 +378,7 @@ def compile_from_input_dict(
                     initial_id=id_,
                     no_optimize=no_optimize,
                     evm_version=evm_version,
+                    no_bytecode_metadata=no_bytecode_metadata,
                 )
             except Exception as exc:
                 return exc_handler(contract_path, exc, "compiler"), {}


Test patch:
Repository: vyperlang/vyper

Issue:
StructureException's message wrongly formatted
### Version Information

* vyper Version: 0.3.8+commit.825fc699
* OS: OSX
* Python Version: 3.8.0

### What's your issue about?

When methods have conflicting IDs (collisions between the 4byte function selectors), the message of the raised `StructureException` does not contain the name of the guilty functions:

Compiling:
```Vyper
@external
def OwnerTransferV7b711143(a : uint256) : 
    pass
@external
def withdraw(a : uint256):
    pass
```
leads to the following output:
```
Error compiling: tests/customs/02.vy
vyper.exceptions.StructureException: Methods have conflicting IDs: 
```

### How can it be fixed?
When defining `collision_str`, `method_ids.values()` should be used instead of `method_ids`
https://github.com/vyperlang/vyper/blob/b13595f4eb7472e298bb118a161f4e85035421cf/vyper/semantics/validation/utils.py#L532
For the example above, the compiler would then output:
```
Error compiling: tests/customs/02.vy
vyper.exceptions.StructureException: Methods have conflicting IDs: OwnerTransferV7b711143, withdraw
```



Discussion:

Resolving patch:
diff --git a/vyper/semantics/validation/utils.py b/vyper/semantics/validation/utils.py
--- a/vyper/semantics/validation/utils.py
+++ b/vyper/semantics/validation/utils.py
@@ -29,7 +29,7 @@
 from vyper.semantics.types.value.boolean import BoolDefinition
 from vyper.semantics.types.value.bytes_fixed import Bytes20Definition  # type: ignore
 from vyper.semantics.validation.levenshtein_utils import get_levenshtein_error_suggestions
-from vyper.utils import checksum_encode
+from vyper.utils import checksum_encode, int_to_fourbytes
 
 
 def _validate_op(node, types_list, validation_fn_name):
@@ -529,5 +529,10 @@ def validate_unique_method_ids(functions: List) -> None:
     method_ids = [x for i in functions for x in i.method_ids.values()]
     collision = next((i for i in method_ids if method_ids.count(i) > 1), None)
     if collision:
-        collision_str = ", ".join(i.name for i in functions if collision in i.method_ids)
-        raise StructureException(f"Methods have conflicting IDs: {collision_str}")
+        collision_str = ", ".join(
+            x for i in functions for x in i.method_ids.keys() if i.method_ids[x] == collision
+        )
+        collision_hex = int_to_fourbytes(collision).hex()
+        raise StructureException(
+            f"Methods produce colliding method ID `0x{collision_hex}`: {collision_str}"
+        )
diff --git a/vyper/utils.py b/vyper/utils.py
--- a/vyper/utils.py
+++ b/vyper/utils.py
@@ -49,6 +49,12 @@ def fourbytes_to_int(inp):
     return (inp[0] << 24) + (inp[1] << 16) + (inp[2] << 8) + inp[3]
 
 
+# Converts an integer to four bytes
+def int_to_fourbytes(n: int) -> bytes:
+    assert n < 2 ** 32
+    return n.to_bytes(4, byteorder="big")
+
+
 def signed_to_unsigned(int_, bits, strict=False):
     """
     Reinterpret a signed integer with n bits as an unsigned integer.


Test patch:
Repository: vyperlang/vyper

Issue:
Compiler crash when shifting by large literal value
### Version Information

* vyper Version (output of `vyper --version`): 0.3.8+commit.2d18e60b
* OS: Linux (Ubuntu 22.04.1 LTS)
* Python Version (output of `python --version`): 3.10.6

### What's your issue about?

The built-in shift function crashes when large shifts are passed as literal.
```vyper
def foo() -> (uint256):
    a: int128 = 2560012123124
    return shift(2, a) 
```
returns 0 as expected, however if we were to pass `a` as a literal:
```vyper
 def foo() -> (uint256):
    return shift(2, 2560012123124)  
``` 
the compiler crashes

The relevant code is at vyper/builtin_functions/functions.py:1511

This seems to be a python issue, since python crashes when evaluating `value = (value << shift) % (2 ** 256) ` with a large shift. (most likely oom due to the large integers)
However the difference in behaviour when passing a literal vs a runtime value is still unexpected Vyper behaviour.

This is not an issue when `shift` is negative, since python does not crash when evaluating a large right-shift.

### How can it be fixed?
Shortcut the result to be 0 when `shift` is larger than 255.



Discussion:
Hmm, probably can just detect that it would be out of bounds like that and throw, no reason to attempt a shift larger than 255
The same issue occurs in PowMod256 for large exponents.

Resolving patch:
diff --git a/vyper/builtins/functions.py b/vyper/builtins/functions.py
--- a/vyper/builtins/functions.py
+++ b/vyper/builtins/functions.py
@@ -1479,8 +1479,11 @@ def evaluate(self, node):
         value, shift = [i.value for i in node.args]
         if value < 0 or value >= 2 ** 256:
             raise InvalidLiteral("Value out of range for uint256", node.args[0])
-        if shift < -(2 ** 127) or shift >= 2 ** 127:
-            raise InvalidLiteral("Value out of range for int128", node.args[1])
+        if shift < -256 or shift > 256:
+            # this validation is performed to prevent the compiler from hanging
+            # rather than for correctness because the post-folded constant would
+            # have been validated anyway
+            raise InvalidLiteral("Shift must be between -256 and 256", node.args[1])
 
         if shift < 0:
             value = value >> -shift


Test patch:
diff --git a/tests/parser/functions/test_bitwise.py b/tests/parser/functions/test_bitwise.py
--- a/tests/parser/functions/test_bitwise.py
+++ b/tests/parser/functions/test_bitwise.py
@@ -2,7 +2,7 @@
 
 from vyper.compiler import compile_code
 from vyper.evm.opcodes import EVM_VERSIONS
-from vyper.exceptions import TypeMismatch
+from vyper.exceptions import InvalidLiteral, TypeMismatch
 
 code = """
 @external
@@ -136,7 +136,23 @@ def foo(x: uint8, y: int128) -> uint256:
     return shift(x, y)
     """,
         TypeMismatch,
-    )
+    ),
+    (
+        """
+@external
+def foo() -> uint256:
+    return shift(2, 257)
+    """,
+        InvalidLiteral,
+    ),
+    (
+        """
+@external
+def foo() -> uint256:
+    return shift(2, -257)
+    """,
+        InvalidLiteral,
+    ),
 ]
Repository: vyperlang/vyper

Issue:
Disallow `++a` unary operations
## Simple Summary

Disallow the (pre-increment) `++a` expression in Vyper for all signed and unsigned types.

```vy
x: uint256 = 0
y: uint256 = 0

# throws
y = x++
# does currently not throw
y = ++x
```

## Motivation

Currently, the (post-increment) expression `a++` throws correctly as it complies with the Python syntax. Unfortunately, Python allows for the expression `++a` which is parsed as `+(+(a)) = a` and therefore is an identity operation on the integer (`+` is here a unary operator). Vyper currently supports this Syntax as well and I think it's more ergonomic & consistent with other languages to disallow it (many non-Python engineers will get confused if they are not aware of the semantics of the syntax). This is one of the design decisions of Python that am not happy about and would recommend not implementing in Vyper either.

## Specification

The compiler should throw an error for any `++a`-like expression for all signed and unsigned types.

## Backwards Compatibility

Will break any previous code that uses a `++a` syntax.

## Dependencies

N/A.

## References

N/A.

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/)



Discussion:

Resolving patch:
diff --git a/vyper/ast/annotation.py b/vyper/ast/annotation.py
--- a/vyper/ast/annotation.py
+++ b/vyper/ast/annotation.py
@@ -230,11 +230,6 @@ def visit_UnaryOp(self, node):
         """
         self.generic_visit(node)
 
-        # TODO once grammar is updated, remove this
-        # UAdd has no effect on the value of it's operand, so it is discarded
-        if isinstance(node.op, python_ast.UAdd):
-            return node.operand
-
         is_sub = isinstance(node.op, python_ast.USub)
         is_num = (
             hasattr(node.operand, "n")


Test patch:
diff --git a/tests/parser/exceptions/test_syntax_exception.py b/tests/parser/exceptions/test_syntax_exception.py
--- a/tests/parser/exceptions/test_syntax_exception.py
+++ b/tests/parser/exceptions/test_syntax_exception.py
@@ -74,6 +74,11 @@ def foo():
     """
 a: internal(uint256)
     """,
+    """
+@external
+def foo():
+    x: uint256 = +1  # test UAdd ast blocked
+    """,
 ]
Repository: vyperlang/vyper

Issue:
`pc_pos_map` for small methods is empty
### Version Information

* vyper Version (output of `vyper --version`): 0.3.7
* OS: osx
* Python Version (output of `python --version`): 3.10.4

### Bug

```
(vyper) ~/vyper $ cat tmp/baz.vy 

@external
def foo():
    pass

(vyper) ~/vyper $ vyc -f source_map tmp/baz.vy 

{"breakpoints": [], "error_map": {"51": "fallback function"}, "pc_breakpoints": [], "pc_jump_map": {"0": "-", "7": "-", "11": "-", "12": "-", "23": "-", "34": "-", "42": "-", "44": "-", "46": "-", "52": "-"}, "pc_pos_map": {}, "pc_pos_map_compressed": "-1:-1:0:-;;;;:::-;;:::-;:::-;;;;;;;:::-;;;;;:::-;;;;;:::-;;:::-;;:::-;;;;:::-;;;"}

```
pc_pos_map should not be empty.




Discussion:

Resolving patch:
diff --git a/vyper/codegen/function_definitions/external_function.py b/vyper/codegen/function_definitions/external_function.py
--- a/vyper/codegen/function_definitions/external_function.py
+++ b/vyper/codegen/function_definitions/external_function.py
@@ -214,4 +214,4 @@ def generate_ir_for_external_function(code, sig, context, skip_nonpayable_check)
         # TODO rethink this / make it clearer
         ret[-1][-1].append(func_common_ir)
 
-    return IRnode.from_list(ret)
+    return IRnode.from_list(ret, source_pos=getpos(sig.func_ast_code))


Test patch:
Repository: vyperlang/vyper

Issue:
variables named `UNREACHABLE` can be shadowed by `raise`and `assert` when used with `UNREACHABLE`
### Version Information

* vyper Version (output of `vyper --version`): 0.3.8+commit.6020b8bb
* OS: OSX
* Python Version (output of `python --version`): 3.8.0

### What's your issue about?

`UNREACHABLE` is not a reserved keyword. For someone who is not familiar with the custom semantic of `UNREACHABLE` when used as a reason string for a `raise` or `assert` statement, the fact that in this context, any previously defined variable named `UNREACHABLE` will be shadowed by this new semantic might be confusing.
To illustrate this, in the following contract, a call to `bar` will revert with `invalid opcode` and not `this is unreachable` as one could imagine.
```Vyper
@external
def bar():
    UNREACHABLE: String[20] = "this is unreachable"
    x: uint256 = 3
    assert 2>x, UNREACHABLE
```
### How can it be fixed?

An option could be to make `UNREACHABLE` a reserved keyword but some other alternative less restrictive might be better.



Discussion:

Resolving patch:
diff --git a/vyper/semantics/namespace.py b/vyper/semantics/namespace.py
--- a/vyper/semantics/namespace.py
+++ b/vyper/semantics/namespace.py
@@ -158,6 +158,7 @@ def validate_identifier(attr):
     "assert",
     "raise",
     "throw",
+    "unreachable",
     # special functions (no name mangling)
     "init",
     "_init_",


Test patch:
Repository: vyperlang/vyper

Issue:
`enum` members can have unexpected structure
### Version Information

* vyper Version (output of `vyper --version`): 0.3.8+commit.4ae2527f
* OS: OSX
* Python Version (output of `python --version`): 3.8.0


Any AST node with an `value` field storing an AST node which itself has an `id` field could be considered as a valid enum member.

For example the following code compiles as the `VariableDecl` has a `value` field which in this case is a `Name` having an `id` field.
```Vyper
enum A:
    a:constant(uint256) = a
```
https://github.com/vyperlang/vyper/blob/d4f04c66bc131ef2d848b29ec49b80f4c836331c/vyper/semantics/types/user.py#L111-L118


Discussion:

Resolving patch:
diff --git a/vyper/semantics/types/user.py b/vyper/semantics/types/user.py
--- a/vyper/semantics/types/user.py
+++ b/vyper/semantics/types/user.py
@@ -106,9 +106,12 @@ def from_EnumDef(cls, base_node: vy_ast.EnumDef) -> "EnumT":
         members: Dict = {}
 
         if len(base_node.body) == 1 and isinstance(base_node.body[0], vy_ast.Pass):
-            raise EnumDeclarationException("Enum must have members")
+            raise EnumDeclarationException("Enum must have members", base_node)
 
         for i, node in enumerate(base_node.body):
+            if not isinstance(node, vy_ast.Expr) or not isinstance(node.value, vy_ast.Name):
+                raise EnumDeclarationException("Invalid syntax for enum member", node)
+
             member_name = node.value.id
             if member_name in members:
                 raise EnumDeclarationException(


Test patch:
diff --git a/tests/parser/syntax/test_enum.py b/tests/parser/syntax/test_enum.py
--- a/tests/parser/syntax/test_enum.py
+++ b/tests/parser/syntax/test_enum.py
@@ -76,6 +76,27 @@ def foo(x: Roles) -> bool:
     """,
         InvalidOperation,
     ),
+    (
+        """
+enum Functions:
+    def foo():nonpayable
+    """,
+        EnumDeclarationException,
+    ),
+    (
+        """
+enum Numbers:
+    a:constant(uint256) = a
+    """,
+        EnumDeclarationException,
+    ),
+    (
+        """
+enum Numbers:
+    12
+    """,
+        EnumDeclarationException,
+    ),
 ]