Tests/Docs: changing type of msg.sender and tx.origin into address

And also making the type of address(literal) as non-payable address.

docs/080-breaking-changes.rst

@@ -65,6 +65,13 @@ This section lists changes that might cause existing contracts to not compile an
      with ``type(uint).max``.
   3. Explicit conversions between literals and enums are only allowed if the literal can
      represent a value in the enum.
+  4. Explicit conversions between literals and ``address`` type (e.g. ``address(literal)``) have the
+     type ``address`` instead of ``address payable``. One can get a payable address type by using an
+     explicit conversion, i.e., ``payable(literal)``.
+
+* :ref:`Address literals<address_literals>` have the type ``address`` instead of ``address
+  payable``. They can be converted to ``address payable`` by using an explicit conversion, e.g.
+  ``payable(0xdCad3a6d3569DF655070DEd06cb7A1b2Ccd1D3AF)``.
 
 * There are new restrictions on explicit type conversions. The conversion is only allowed when there
   is at most one change in sign, width or type-category (``int``, ``address``, ``bytesNN``, etc.).
@@ -105,6 +112,12 @@ This section lists changes that might cause existing contracts to not compile an
 
 * Remove support for the ``\b``, ``\f``, and ``\v`` escape sequences in code.
   They can still be inserted via hexadecimal escapes, e.g. ``\x08``, ``\x0c``, and ``\x0b``, respectively.
+* The global variables ``tx.origin`` and ``msg.sender`` have the type ``address`` instead of
+  ``address payable``. One can convert them into ``address payable`` by using an explicit
+  conversion, i.e., ``payable(tx.origin)`` or ``payable(msg.sender)``.
+
+  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.
 
 * The ``chainid`` builtin in inline assembly is now considered ``view`` instead of ``pure``.
 

docs/common-patterns.rst

@@ -53,7 +53,7 @@ you receive the funds of the person who is now the richest.
             // Remember to zero the pending refund before
             // sending to prevent re-entrancy attacks
             pendingWithdrawals[msg.sender] = 0;
-            msg.sender.transfer(amount);
+            payable(msg.sender).transfer(amount);
         }
     }
 
@@ -69,7 +69,7 @@ This is as opposed to the more intuitive sending pattern:
         uint public mostSent;
 
         constructor() payable {
-            richest = msg.sender;
+            richest = payable(msg.sender);
             mostSent = msg.value;
         }
 
@@ -77,7 +77,7 @@ This is as opposed to the more intuitive sending pattern:
             require(msg.value > mostSent, "Not enough money sent.");
             // This line can cause problems (explained below).
             richest.transfer(msg.value);
-            richest = msg.sender;
+            richest = payable(msg.sender);
             mostSent = msg.value;
         }
     }
@@ -124,7 +124,7 @@ restrictions highly readable.
 ::
 
     // SPDX-License-Identifier: GPL-3.0
-    pragma solidity >=0.4.22 <0.9.0;
+    pragma solidity >=0.6.0 <0.9.0;
 
     contract AccessRestriction {
         // These will be assigned at the construction
@@ -192,7 +192,7 @@ restrictions highly readable.
             );
             _;
             if (msg.value > _amount)
-                msg.sender.transfer(msg.value - _amount);
+                payable(msg.sender).transfer(msg.value - _amount);
         }
 
         function forceOwnerChange(address _newOwner)

docs/contracts/function-modifiers.rst

@@ -21,7 +21,7 @@ if they are marked ``virtual``. For details, please see
     pragma solidity >0.7.0 <0.9.0;
 
     contract owned {
-        constructor() { owner = msg.sender; }
+        constructor() { owner = payable(msg.sender); }
         address payable owner;
 
         // This contract only defines a modifier but does not use

docs/contracts/inheritance.rst

@@ -43,7 +43,7 @@ Details are given in the following example.
 
 
     contract Owned {
-        constructor() { owner = msg.sender; }
+        constructor() { owner = payable(msg.sender); }
         address payable owner;
     }
 
@@ -130,7 +130,7 @@ seen in the following example::
     pragma solidity >=0.7.0 <0.9.0;
 
     contract owned {
-        constructor() { owner = msg.sender; }
+        constructor() { owner = payable(msg.sender); }
         address payable owner;
     }
 
@@ -160,7 +160,7 @@ explicitly in the final override, but this function will bypass
     pragma solidity >=0.7.0 <0.9.0;
 
     contract owned {
-        constructor() { owner = msg.sender; }
+        constructor() { owner = payable(msg.sender); }
         address payable owner;
     }
 

docs/examples/blind-auction.rst

@@ -114,7 +114,7 @@ to receive their money - contracts cannot activate themselves.
                 // before `send` returns.
                 pendingReturns[msg.sender] = 0;
 
-                if (!msg.sender.send(amount)) {
+                if (!payable(msg.sender).send(amount)) {
                     // No need to call throw here, just reset the amount owing
                     pendingReturns[msg.sender] = amount;
                     return false;
@@ -280,7 +280,7 @@ invalid bids.
                 // the same deposit.
                 bidToCheck.blindedBid = bytes32(0);
             }
-            msg.sender.transfer(refund);
+            payable(msg.sender).transfer(refund);
         }
 
         /// Withdraw a bid that was overbid.
@@ -293,7 +293,7 @@ invalid bids.
                 // conditions -> effects -> interaction).
                 pendingReturns[msg.sender] = 0;
 
-                msg.sender.transfer(amount);
+                payable(msg.sender).transfer(amount);
             }
         }
 

docs/examples/micropayment.rst

@@ -159,13 +159,13 @@ The full contract
 
             require(recoverSigner(message, signature) == owner);
 
-            msg.sender.transfer(amount);
+            payable(msg.sender).transfer(amount);
         }
 
         /// destroy the contract and reclaim the leftover funds.
         function shutdown() public {
             require(msg.sender == owner);
-            selfdestruct(msg.sender);
+            selfdestruct(payable(msg.sender));
         }
 
         /// signature methods.
@@ -347,7 +347,7 @@ The full contract
         constructor (address payable _recipient, uint256 duration)
             payable
         {
-            sender = msg.sender;
+            sender = payable(msg.sender);
             recipient = _recipient;
             expiration = block.timestamp + duration;
         }

docs/examples/safe-remote.rst

@@ -74,7 +74,7 @@ you can use state machine-like constructs inside a contract.
         // Division will truncate if it is an odd number.
         // Check via multiplication that it wasn't an odd number.
         constructor() payable {
-            seller = msg.sender;
+            seller = payable(msg.sender);
             value = msg.value / 2;
             require((2 * value) == msg.value, "Value has to be even.");
         }
@@ -107,7 +107,7 @@ you can use state machine-like constructs inside a contract.
             payable
         {
             emit PurchaseConfirmed();
-            buyer = msg.sender;
+            buyer = payable(msg.sender);
             state = State.Locked;
         }
 

docs/security-considerations.rst

@@ -59,7 +59,7 @@ complete contract):
 ::
 
     // SPDX-License-Identifier: GPL-3.0
-    pragma solidity >=0.4.0 <0.9.0;
+    pragma solidity >=0.6.0 <0.9.0;
 
     // THIS CONTRACT CONTAINS A BUG - DO NOT USE
     contract Fund {
@@ -67,7 +67,7 @@ complete contract):
         mapping(address => uint) shares;
         /// Withdraw your share.
         function withdraw() public {
-            if (msg.sender.send(shares[msg.sender]))
+            if (payable(msg.sender).send(shares[msg.sender]))
                 shares[msg.sender] = 0;
         }
     }
@@ -103,7 +103,7 @@ outlined further below:
 ::
 
     // SPDX-License-Identifier: GPL-3.0
-    pragma solidity >=0.4.11 <0.9.0;
+    pragma solidity >=0.6.0 <0.9.0;
 
     contract Fund {
         /// @dev Mapping of ether shares of the contract.
@@ -112,7 +112,7 @@ outlined further below:
         function withdraw() public {
             uint share = shares[msg.sender];
             shares[msg.sender] = 0;
-            msg.sender.transfer(share);
+            payable(msg.sender).transfer(share);
         }
     }
 
@@ -230,7 +230,7 @@ Now someone tricks you into sending Ether to the address of this attack wallet:
         address payable owner;
 
         constructor() {
-            owner = msg.sender;
+            owner = payable(msg.sender);
         }
 
         receive() external payable {

docs/types/value-types.rst

@@ -188,25 +188,22 @@ Type conversions:
 Implicit conversions from ``address payable`` to ``address`` are allowed, whereas conversions from ``address`` to ``address payable``
 must be explicit via ``payable(<address>)``.
 
-:ref:`Address literals<address_literals>` can be implicitly converted to ``address payable``.
-
 Explicit conversions to and from ``address`` are allowed for integers, integer literals, ``bytes20`` and contract types with the following
 caveat:
 The result of a conversion of the form ``address(x)``
 has the type ``address payable``, if ``x`` is of integer or fixed bytes type,
-a literal or a contract with a receive or payable fallback function.
+or a contract with a receive or payable fallback function.
 If ``x`` is a contract without a receive or payable fallback function,
 then ``address(x)`` will be of type ``address``.
+Similarly, if ``x`` is a literal, then ``address(x)`` will also be of type ``address``.
 In external function signatures ``address`` is used for both the ``address`` and the ``address payable`` type.
 
 Only expressions of type ``address`` can be converted to type ``address payable`` via ``payable(<address>)``.
 
 .. note::
-    It might very well be that you do not need to care about the distinction between ``address``
-    and ``address payable`` and just use ``address`` everywhere. For example,
-    if you are using the :ref:`withdrawal pattern<withdrawal_pattern>`, you can (and should) store the
-    address itself as ``address``, because you invoke the ``transfer`` function on
-    ``msg.sender``, which is an ``address payable``.
+    If you need a variable of type ``address`` and plan to send Ether to it, then
+    declare its type as ``address payable`` to make this requirement visible. Also,
+    try to make this distinction or conversion as early as possible.
 
 Operators:
 
@@ -410,7 +407,7 @@ Address Literals
 ----------------
 
 Hexadecimal literals that pass the address checksum test, for example
-``0xdCad3a6d3569DF655070DEd06cb7A1b2Ccd1D3AF`` are of ``address payable`` type.
+``0xdCad3a6d3569DF655070DEd06cb7A1b2Ccd1D3AF`` are of ``address`` type.
 Hexadecimal literals that are between 39 and 41 digits
 long and do not pass the checksum test produce
 an error. You can prepend (for integer types) or append (for bytesNN types) zeros to remove the error.