Merge branch 'master' into fix/add-node-info-to-module-not-found

docs/compiling-a-contract.rst

@@ -106,7 +106,7 @@ Online Compilers
 Try VyperLang!
 -----------------
 
-`Try VyperLang! <https://try.vyperlang.org>`_ is a JupterHub instance hosted by the Vyper team as a sandbox for developing and testing contracts in Vyper. It requires github for login, and supports deployment via the browser.
+`Try VyperLang! <https://try.vyperlang.org>`_ is a JupyterHub instance hosted by the Vyper team as a sandbox for developing and testing contracts in Vyper. It requires github for login, and supports deployment via the browser.
 
 Remix IDE
 ---------
@@ -203,7 +203,7 @@ The following is a list of supported EVM versions, and changes in the compiler i
 Integrity Hash
 ==============
 
-To help tooling detect whether two builds are the same, Vyper provides the ``-f integrity`` output, which outputs the integrity hash of a contract. The integrity hash is recursively defined as the sha256 of the source code with the integrity hashes of its dependencies (imports).
+To help tooling detect whether two builds are the same, Vyper provides the ``-f integrity`` output, which outputs the integrity hash of a contract. The integrity hash is recursively defined as the sha256 of the source code with the integrity hashes of its dependencies (imports) and storage layout overrides (if provided).
 
 .. _vyper-archives:
 
@@ -219,15 +219,17 @@ A Vyper archive is a compileable bundle of input sources and settings. Technical
     ├── compilation_targets
     ├── compiler_version
     ├── integrity
+    ├── settings.json
     ├── searchpaths
-    └── settings.json
+    └── storage_layout.json [OPTIONAL]
 
 * ``cli_settings.txt`` is a text representation of the settings that were used on the compilation run that generated this archive.
 * ``compilation_targets`` is a newline separated list of compilation targets. Currently only one compilation is supported
 * ``compiler_version`` is a text representation of the compiler version used to generate this archive
 * ``integrity`` is the :ref:`integrity hash <integrity-hash>` of the input contract
 * ``searchpaths`` is a newline-separated list of the search paths used on this compilation run
 * ``settings.json`` is a json representation of the settings used on this compilation run. It is 1:1 with ``cli_settings.txt``, but both are provided as they are convenient for different workflows (typically, manually vs automated).
+* ``storage_layout.json`` is a json representation of the storage layout overrides to be used on this compilation run. It is optional.
 
 A Vyper archive file can be produced by requesting the ``-f archive`` output format. The compiler can also produce the archive in base64 encoded form using the ``--base64`` flag. The Vyper compiler can accept both ``.vyz`` and base64-encoded Vyper archives directly as input.
 
@@ -281,6 +283,14 @@ The following example describes the expected input format of ``vyper-json``. (Co
             }
         },
         // Optional
+        // Storage layout overrides for the contracts that are compiled
+        "storage_layout_overrides": {
+            "contracts/foo.vy": {
+                "a": {"type": "uint256", "slot": 1, "n_slots": 1},
+                "b": {"type": "uint256", "slot": 0, "n_slots": 1},
+            }
+        },
+        // Optional
         "settings": {
             "evmVersion": "cancun",  // EVM version to compile for. Can be london, paris, shanghai or cancun (default).
             // optional, optimization mode
@@ -364,6 +374,13 @@ The following example describes the output format of ``vyper-json``. Comments ar
             "formattedMessage": "line 5:11 Unsupported type conversion: int128 to bool"
             }
         ],
+        // Optional: not present if there are no storage layout overrides
+        "storage_layout_overrides": {
+            "contracts/foo.vy": {
+                "a": {"type": "uint256", "slot": 1, "n_slots": 1},
+                "b": {"type": "uint256", "slot": 0, "n_slots": 1},
+            }
+        },
         // This contains the file-level outputs. Can be limited/filtered by the outputSelection settings.
         "sources": {
             "source_file.vy": {

docs/control-structures.rst

@@ -48,7 +48,16 @@ External functions (marked with the ``@external`` decorator) are a part of the c
 A Vyper contract cannot call directly between two external functions. If you must do this, you can use an :ref:`interface <interfaces>`.
 
 .. note::
-    For external functions with default arguments like ``def my_function(x: uint256, b: uint256 = 1)`` the Vyper compiler will generate ``N+1`` overloaded function selectors based on ``N`` default arguments.
+    For external functions with default arguments like ``def my_function(x: uint256, b: uint256 = 1)`` the Vyper compiler will generate ``N+1`` overloaded function selectors based on ``N`` default arguments. Consequently, the ABI signature for a function (this includes interface functions) excludes optional arguments when their default values are used in the function call.
+
+    .. code-block:: vyper
+
+        from ethereum.ercs import IERC4626
+
+        @external
+        def foo(x: IERC4626):
+            extcall x.withdraw(0, self, self)   # keccak256("withdraw(uint256,address,address)")[:4] = 0xb460af94
+            extcall x.withdraw(0)               # keccak256("withdraw(uint256)")[:4] = 0x2e1a7d4d
 
 .. _structure-functions-internal:
 
@@ -75,6 +84,14 @@ Or for internal functions which are defined in :ref:`imported modules <modules>`
     def calculate(amount: uint256) -> uint256:
         return calculator_library._times_two(amount)
 
+Marking an internal function as ``payable`` specifies that the function can interact with ``msg.value``. A ``nonpayable`` internal function can be called from an external ``payable`` function, but it cannot access ``msg.value``.
+
+.. code-block:: vyper
+
+    @payable
+    def _foo() -> uint256:
+        return msg.value % 2
+
 .. note::
    As of v0.4.0, the ``@internal`` decorator is optional. That is, functions with no visibility decorator default to being ``internal``.
 
@@ -110,7 +127,7 @@ You can optionally declare a function's mutability by using a :ref:`decorator <f
     * ``@pure``: does not read from the contract state or any environment variables.
     * ``@view``: may read from the contract state, but does not alter it.
     * ``@nonpayable`` (default): may read from and write to the contract state, but cannot receive Ether.
-    * ``@payable``: may read from and write to the contract state, and can receive Ether.
+    * ``@payable``: may read from and write to the contract state, and can receive and access Ether via ``msg.value``.
 
 .. code-block:: vyper
 
@@ -132,6 +149,9 @@ Functions marked with ``@view`` cannot call mutable (``payable`` or ``nonpayable
 
 Functions marked with ``@pure`` cannot call non-``pure`` functions.
 
+.. note::
+    The ``@nonpayable`` decorator is not strictly enforced on ``internal`` functions when they are invoked through an ``external`` ``payable`` function. As a result, an ``external`` ``payable`` function can invoke an ``internal`` ``nonpayable`` function. However, the ``nonpayable`` ``internal`` function cannot have access to ``msg.value``.
+
 Re-entrancy Locks
 -----------------
 

docs/interfaces.rst

@@ -120,6 +120,10 @@ This imports the defined interface from the vyper file at ``an_interface.vyi`` (
 
   Prior to v0.4.0, ``implements`` required that events defined in an interface were re-defined in the "implementing" contract. As of v0.4.0, this is no longer required because events can be used just by importing them. Any events used in a contract will automatically be exported in the ABI output.
 
+.. note::
+
+  An interface function with default parameters (e.g. ``deposit(assets: uint256, receiver: address = msg.sender)``) implies that the contract being interfaced with supports these default arguments via the ABI-encoded function signatures (e.g. ``keccak256("deposit(uint256,address)")[:4]`` and ``keccak256("deposit(uint256)")[:4]``). It is the responsibility of the callee to implement the behavior associated with these defaults.
+
 Standalone Interfaces
 =====================
 

tests/unit/cli/storage_layout/test_storage_layout_overrides.py

@@ -2,6 +2,7 @@
 
 import pytest
 
+from vyper.cli.vyper_json import compile_json
 from vyper.compiler import compile_code
 from vyper.evm.opcodes import version_check
 from vyper.exceptions import StorageLayoutException
@@ -13,7 +14,7 @@ def test_storage_layout_overrides():
 b: uint256"""
 
     storage_layout_overrides = {
-        "a": {"type": "uint256", "slot": 1, "n_slots": 1},
+        "a": {"type": "uint256", "slot": 5, "n_slots": 1},
         "b": {"type": "uint256", "slot": 0, "n_slots": 1},
     }
 
@@ -26,6 +27,31 @@ def test_storage_layout_overrides():
     assert out["layout"] == expected_output
 
 
+def test_storage_layout_overrides_json():
+    code = """
+a: uint256
+b: uint256"""
+
+    storage_layout_overrides = {
+        "a": {"type": "uint256", "slot": 5, "n_slots": 1},
+        "b": {"type": "uint256", "slot": 0, "n_slots": 1},
+    }
+
+    input_json = {
+        "language": "Vyper",
+        "sources": {"contracts/foo.vy": {"content": code}},
+        "storage_layout_overrides": {"contracts/foo.vy": storage_layout_overrides},
+        "settings": {"outputSelection": {"*": ["*"]}},
+    }
+
+    out = compile_code(
+        code, output_formats=["layout"], storage_layout_override=storage_layout_overrides
+    )
+    assert (
+        compile_json(input_json)["contracts"]["contracts/foo.vy"]["foo"]["layout"] == out["layout"]
+    )
+
+
 def test_storage_layout_for_more_complex():
     code = """
 foo: HashMap[address, uint256]