All explicit address conversions return a non-payable address

This commit is contained in:
hrkrshnn 2020-12-14 16:36:40 +01:00
parent 88c99a7538
commit f30c7cbac8
3 changed files with 17 additions and 12 deletions

View File

@ -27,7 +27,7 @@ Breaking Changes:
* Type System: Support ``address(...).codehash`` to retrieve the codehash of an account. * Type System: Support ``address(...).codehash`` to retrieve the codehash of an account.
* Type System: Unary negation can only be used on signed integers, not on unsigned integers. * Type System: Unary negation can only be used on signed integers, not on unsigned integers.
* View Pure Checker: Mark ``chainid`` as view. * View Pure Checker: Mark ``chainid`` as view.
* Type System: Address-literals and explicit conversions of integer-literals into ``address `` have type ``address`` instead of ``address payable``. * Type System: Explicit conversion to ``address`` type always returns a non-payable ``address`` type. In particular, ``address(u)``, ``address(b)``, ``address(c)`` and ``address(this)`` have the type ``address`` instead of ``address payable`` (Here ``u``, ``b``, and ``c`` are arbitrary variables of type ``uint160``, ``bytes20`` and contract type respectively.)
* Type System: The global variables ``tx.origin`` and ``msg.sender`` have type ``address`` instead of ``address payable``. * Type System: The global variables ``tx.origin`` and ``msg.sender`` have type ``address`` instead of ``address payable``.
* Yul: Disallow the use of reserved identifiers, such as EVM instructions, even if they are not available in the given dialect / EVM version. * Yul: Disallow the use of reserved identifiers, such as EVM instructions, even if they are not available in the given dialect / EVM version.

View File

@ -119,6 +119,22 @@ This section lists changes that might cause existing contracts to not compile an
This change was done since the compiler cannot determine whether or not these addresses This change was done since the compiler cannot determine whether or not these addresses
are payable or not, so it now requires an explicit conversion to make this requirement visible. are payable or not, so it now requires an explicit conversion to make this requirement visible.
* Explicit conversion into ``address`` type always returns a non-payable ``address`` type. In
particular, the following explicit conversions have the type ``address`` instead of ``address
payable``:
- ``address(u)`` where ``u`` is an arbitrary variable of type ``uint160``. One can convert ``u``
into the type ``address payable`` by using an explicit conversion, i.e., ``payable(u)``.
- ``address(b)`` where ``b`` is an arbitrary variable of type ``bytes20``. One can convert ``b``
into the type ``address payable`` by using an explicit conversion, i.e., ``payable(bytes20)``.
- ``address(c)`` where ``c`` is an arbitrary contract. Previously, the return type of this
conversion depended on whether the contract can receive Ether (either by having a receive
function or a payable fallback function). The conversion ``payable(c)`` has the type ``address
payable`` and is only allowed when the contract ``c`` can receive Ether. In general, one can
always convert ``c`` into the type ``address payable`` by using the following explicit
conversion: ``payable(address(c))``. Note that ``address(this)`` falls under the same category
as ``address(c)`` and the same rules apply for it.
* The ``chainid`` builtin in inline assembly is now considered ``view`` instead of ``pure``. * The ``chainid`` builtin in inline assembly is now considered ``view`` instead of ``pure``.
Interface Changes Interface Changes

View File

@ -1764,17 +1764,6 @@ TypePointer TypeChecker::typeCheckTypeConversionAndRetrieveReturnType(
result.message() result.message()
); );
} }
if (auto addressType = dynamic_cast<AddressType const*>(resultType))
if (addressType->stateMutability() != StateMutability::Payable)
{
bool payable = false;
if (
argType->category() != Type::Category::Address &&
argType->category() != Type::Category::RationalNumber
)
payable = argType->isExplicitlyConvertibleTo(*TypeProvider::payableAddress());
resultType = payable ? TypeProvider::payableAddress() : TypeProvider::address();
}
} }
return resultType; return resultType;
} }