NoBey/openzeppelin-contracts
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

merge api docs changes

Browse Source 
Squashed commit of the following:

commit 06243c3e8e86074ff8e9e3f22b7829a2c315d707
Merge: 991882ec 99373558
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 18:15:37 2019 -0300

    Merge branch 'api-docs' into api-docs-merge

commit 991882eca5bb8a3391995154bfb9d53d8a69cb4f
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 18:08:02 2019 -0300

    manually apply docs changes and renamings

commit fa1f6e97dd67a76c3cd828d0a5e19b4ac6c37acb
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 17:36:03 2019 -0300

    move functions to new order

commit 99373558e3af4905d29bc6f3f542ba93d28a24ab
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 16:23:40 2019 -0300

    add missing docs links

commit d180d6c36a6f5460e85473ee5a18992d1449a6ff
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 16:14:12 2019 -0300

    update solidity-docgen dependency

    fixes uri encoded links

commit faab0e50da91cd2f0a409e3ad32e2db127ad319a
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 16:05:03 2019 -0300

    update openzeppelin-docsite and solidity-docgen dependencies

    add visibility specifiers

commit ef305268bb2735e488e35d16819a4b432b3a35e3
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Thu May 23 15:36:45 2019 -0300

    Fix guide links.

commit 339b20dbfa2d5f6ea02e63c2f3fdcba0fe879c3c
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Thu May 23 13:37:51 2019 -0300

    Fix typos.

commit 6c7b97460578b9eea90b53c280454e361f8f0052
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 15:26:29 2019 -0300

    fix utilities guide links

commit 0e7692a8fd8516a11becc4121d77d792439600b1
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 15:23:19 2019 -0300

    update solidity-docgen dependency

commit ebb8a8651516ece21736c6c3b2577eb1b3487651
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 15:15:01 2019 -0300

    fix utilities guide links

commit 5ec47d62785e1d6e5f8e91edca58f2dc7f87d7a3
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 15:14:49 2019 -0300

    fix escrow docs ordering

commit cdcdc909b16f219a9a3272036b6a8f21e34b48ef
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 13:35:07 2019 -0300

    add wip notice

commit 987e2951ae93211c8c70c8288e30573555c57830
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 13:09:35 2019 -0300

    update openzeppelin-docsite dependency

    fixes links to old versions

commit b00d22c0affac2e2108df8b773dfa1706afcb44e
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 23 13:09:28 2019 -0300

    fix guide links

commit f112a9400c5e5ad495c8e0fdb972e26987b34244
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 20:42:37 2019 -0300

    update docsite

commit 68aacdd56a29e35a84f6732f9293612bbcaf7520
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Wed May 22 20:00:39 2019 -0300

    ERC20Capped

commit 4edce78bab2c6d140f3ea3f33db71e92ca4d8aaf
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Wed May 22 19:52:30 2019 -0300

    Unnecessary polish on token docs.

commit 2a4c91cf49c2736dc09c1c03cf383911def1a1b2
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 19:20:05 2019 -0300

    rename guides

commit 61dd818ea76d4c170c4ab175c6be0d6067d21a29
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Wed May 22 17:04:09 2019 -0300

    ERC1820 docs.

commit 77b5f0353123b76358dc6d86bdc646c86c9b0bea
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Wed May 22 16:17:34 2019 -0300

    Introspection and ERC165.

commit 76641a253b3b70279802c5134dd107532eea4b2c
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 17:59:53 2019 -0300

    update docgen

commit 7be98bc3fbd3566231f943f01b9acb58567d755b
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 17:23:50 2019 -0300

    update solidity-docgen

commit f7268e6e010f8ef9ac83df241a803f91efc08c0c
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 16:58:31 2019 -0300

    update docgen

commit 2a8c7a378e8962a5baeb334b2492815f05075f98
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Wed May 22 14:36:35 2019 -0300

    Util docs.

commit 327ae8ff45a1a523c7591bf4996c4a9b52d7ec7a
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 13:08:50 2019 -0300

    add missing drafts

commit 5e7f71335ac8423c0e363ae8c7ad9b2977f202f8
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 12:47:41 2019 -0300

    tweak ierc20 docs

commit cd0e86a0b712f74ffd406e072d4b1fbf4dd2c176
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 12:46:45 2019 -0300

    add some erc721 docs

commit e081184159417f71da14bc0fc110b7b11e29d75d
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 12:41:46 2019 -0300

    update docsite

commit 0beb75784022419d47123c2a9fe7a5f1eb87f9b2
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 12:22:27 2019 -0300

    correct drafts structure

commit 2e94b287c7cead7a6c0603205670566461c31abb
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 11:56:25 2019 -0300

    fix docsite-start script

commit 0fa4160484309d0851584fe57c0d81a3600977db
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 11:47:44 2019 -0300

    improve docsite start script (automatically watch docgen)

commit 9d571897cc03bee92035964cf7a2cfeda1e2f690
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 22 11:30:37 2019 -0300

    update solidity-docgen

commit 82980f5aefbdfb8a9815a3b7b0e88e970b65dd5d
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Tue May 21 19:15:13 2019 -0300

    edit docs for Secondary

commit 00d7a005b0530bee730b77a1b69a95f1b4ffe315
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Tue May 21 19:15:13 2019 -0300

    edit docs for ownable

commit b0c4c2bdf83eca5d4a71792daac603236733d46e
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Tue May 21 18:27:13 2019 -0300

    change title of Math section

commit deb788583f191780e55b7f673520eaf13a5c7e23
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Tue May 21 18:26:59 2019 -0300

    capitalization

commit f2bcf85d343ea4a0739fe22a77b1e22c2296ddea
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Tue May 21 18:26:06 2019 -0300

    edit docs for Pausable

commit 73ba0cf43dbb44c39c1bf2ee63ef9fe558faa919
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Sat May 18 19:08:06 2019 -0300

    Crypto docs.

commit 9d6fc6223f51cf2321b2e3217c512579654c3917
Merge: 7e21f8f7 9f1cec12
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Fri May 17 17:23:15 2019 -0300

    Merge branch 'api-docs-777' into api-docs

commit 9f1cec12e3351fb1b5fc0b59f5ded39928064a56
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Fri May 17 17:22:54 2019 -0300

    ERC777 done.

commit 7e21f8f7b6982d2f92df302cdf6ec62522d8ffff
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Fri May 17 16:39:47 2019 -0300

    add math docs

commit f18d1f17023b6e5b42ae04fc38aa1170e6863864
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Thu May 16 20:01:46 2019 -0300

    First draft of ERC777 docs.

commit 985c5d3053
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Thu May 16 19:14:32 2019 -0300

    Final draft for IERC777.

commit bf53f133d987b67f938a329e6d659ba3483aab0b
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 16 19:13:37 2019 -0300

    more work on ERC20 api docs

commit b7c250b7cb
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Thu May 16 17:08:47 2019 -0300

    Fix typo.

commit 197bbfbfc6
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Thu May 16 17:05:14 2019 -0300

    Initial draft of IERC777.

commit 7dc3b55161c860437a8f13a2ce5808b1c3dd70a2
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Thu May 16 11:58:32 2019 -0300

    add payment docs structure

commit da16fc4480
Author: Nicolás Venturo <nicolas.venturo@gmail.com>
Date:   Thu May 16 16:05:33 2019 -0300

    Initial ERC777 docstrings.

commit 9f6a7e35bd
Author: Francisco Giordano <frangio.1@gmail.com>
Date:   Wed May 15 22:13:17 2019 -0300

    partial pass through ERC20 docs
This commit is contained in:
Francisco Giordano
2019-05-23 18:17:07 -03:00
parent 036dd9bd6e
commit 2f9ae975c8
53 changed files with 3233 additions and 901 deletions
Download Patch File Download Diff File Expand all files Collapse all files

233
contracts/token/ERC20/ERC20.sol
View File

@ -4,16 +4,27 @@ import "./IERC20.sol";
import "../../math/SafeMath.sol";
/**
* @title Standard ERC20 token
* @dev Implementation of the `IERC20` interface.
*
* @dev Implementation of the basic standard token.
* https://eips.ethereum.org/EIPS/eip-20
* Originally based on code by FirstBlood:
* https://github.com/Firstbloodio/token/blob/master/smart_contract/FirstBloodToken.sol
* This implementation is agnostic to the way tokens are created. This means
* that a supply mechanism has to be added in a derived contract using `_mint`.
* For a generic mechanism see `ERC20Mintable`.
*
* This implementation emits additional Approval events, allowing applications to reconstruct the allowance status for
* all accounts just by listening to said events. Note that this isn't required by the specification, and other
* compliant implementations may not do it.
* *For a detailed writeup see our guide [How to implement supply
* mechanisms](https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226).*
*
* We have followed general OpenZeppelin guidelines: functions revert instead
* of returning `false` on failure. This behavior is nonetheless conventional
* and does not conflict with the expectations of ERC20 applications.
*
* Additionally, an `Approval` event is emitted on calls to `transferFrom`.
* This allows applications to reconstruct the allowance for all accounts just
* by listening to said events. Other implementations of the EIP may not emit
* these events, as it isn't required by the specification.
*
* Finally, the non-standard `decreaseAllowance` and `increaseAllowance`
* functions have been added to mitigate the well-known issues around setting
* allowances. See `IERC20.approve`.
*/
contract ERC20 is IERC20 {
using SafeMath for uint256;
@ -25,49 +36,45 @@ contract ERC20 is IERC20 {
uint256 private _totalSupply;
/**
* @dev Total number of tokens in existence.
* @dev See `IERC20.totalSupply`.
*/
function totalSupply() public view returns (uint256) {
return _totalSupply;
}
/**
* @dev Gets the balance of the specified address.
* @param owner The address to query the balance of.
* @return A uint256 representing the amount owned by the passed address.
* @dev See `IERC20.balanceOf`.
*/
function balanceOf(address owner) public view returns (uint256) {
return _balances[owner];
function balanceOf(address account) public view returns (uint256) {
return _balances[account];
}
/**
* @dev Function to check the amount of tokens that an owner allowed to a spender.
* @param owner address The address which owns the funds.
* @param spender address The address which will spend the funds.
* @return A uint256 specifying the amount of tokens still available for the spender.
* @dev See `IERC20.transfer`.
*
* Requirements:
*
* - `recipient` cannot be the zero address.
* - the caller must have a balance of at least `amount`.
*/
function transfer(address recipient, uint256 amount) public returns (bool) {
_transfer(msg.sender, recipient, amount);
return true;
}
/**
* @dev See `IERC20.allowance`.
*/
function allowance(address owner, address spender) public view returns (uint256) {
return _allowances[owner][spender];
}
/**
* @dev Transfer token to a specified address.
* @param to The address to transfer to.
* @param value The amount to be transferred.
*/
function transfer(address to, uint256 value) public returns (bool) {
_transfer(msg.sender, to, value);
return true;
}
/**
* @dev Approve the passed address to spend the specified amount of tokens on behalf of msg.sender.
* Beware that changing an allowance with this method brings the risk that someone may use both the old
* and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this
* race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards:
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
* @param spender The address which will spend the funds.
* @param value The amount of tokens to be spent.
* @dev See `IERC20.approve`.
*
* Requirements:
*
* - `spender` cannot be the zero address.
*/
function approve(address spender, uint256 value) public returns (bool) {
_approve(msg.sender, spender, value);
@ -75,28 +82,34 @@ contract ERC20 is IERC20 {
}
/**
* @dev Transfer tokens from one address to another.
* Note that while this function emits an Approval event, this is not required as per the specification,
* and other compliant implementations may not emit the event.
* @param from address The address which you want to send tokens from
* @param to address The address which you want to transfer to
* @param value uint256 the amount of tokens to be transferred
* @dev See `IERC20.transferFrom`.
*
* Emits an `Approval` event indicating the updated allowance. This is not
* required by the EIP. See the note at the beginning of `ERC20`;
*
* Requirements:
* - `sender` and `recipient` cannot be the zero address.
* - `sender` must have a balance of at least `value`.
* - the caller must have allowance for `sender`'s tokens of at least
* `amount`.
*/
function transferFrom(address from, address to, uint256 value) public returns (bool) {
_transfer(from, to, value);
_approve(from, msg.sender, _allowances[from][msg.sender].sub(value));
function transferFrom(address sender, address recipient, uint256 amount) public returns (bool) {
_transfer(sender, recipient, amount);
_approve(sender, msg.sender, _allowances[sender][msg.sender].sub(amount));
return true;
}
/**
* @dev Increase the amount of tokens that an owner allowed to a spender.
* approve should be called when _allowances[msg.sender][spender] == 0. To increment
* allowed value is better to use this function to avoid 2 calls (and wait until
* the first transaction is mined)
* From MonolithDAO Token.sol
* Emits an Approval event.
* @param spender The address which will spend the funds.
* @param addedValue The amount of tokens to increase the allowance by.
* @dev Atomically increases the allowance granted to `spender` by the caller.
*
* This is an alternative to `approve` that can be used as a mitigation for
* problems described in `IERC20.approve`.
*
* Emits an `Approval` event indicating the updated allowance.
*
* Requirements:
*
* - `spender` cannot be the zero address.
*/
function increaseAllowance(address spender, uint256 addedValue) public returns (bool) {
_approve(msg.sender, spender, _allowances[msg.sender][spender].add(addedValue));
@ -104,14 +117,18 @@ contract ERC20 is IERC20 {
}
/**
* @dev Decrease the amount of tokens that an owner allowed to a spender.
* approve should be called when _allowances[msg.sender][spender] == 0. To decrement
* allowed value is better to use this function to avoid 2 calls (and wait until
* the first transaction is mined)
* From MonolithDAO Token.sol
* Emits an Approval event.
* @param spender The address which will spend the funds.
* @param subtractedValue The amount of tokens to decrease the allowance by.
* @dev Atomically decreases the allowance granted to `spender` by the caller.
*
* This is an alternative to `approve` that can be used as a mitigation for
* problems described in `IERC20.approve`.
*
* Emits an `Approval` event indicating the updated allowance.
*
* Requirements:
*
* - `spender` cannot be the zero address.
* - `spender` must have allowance for the caller of at least
* `subtractedValue`.
*/
function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool) {
_approve(msg.sender, spender, _allowances[msg.sender][spender].sub(subtractedValue));
@ -119,40 +136,55 @@ contract ERC20 is IERC20 {
}
/**
* @dev Transfer token for a specified addresses.
* @param from The address to transfer from.
* @param to The address to transfer to.
* @param value The amount to be transferred.
* @dev Moves tokens `amount` from `sender` to `recipient`.
*
* This is internal function is equivalent to `transfer`, and can be used to
* e.g. implement automatic token fees, slashing mechanisms, etc.
*
* Emits a `Transfer` event.
*
* Requirements:
*
* - `sender` cannot be the zero address.
* - `recipient` cannot be the zero address.
* - `sender` must have a balance of at least `amount`.
*/
function _transfer(address from, address to, uint256 value) internal {
require(from != address(0), "ERC20: transfer from the zero address");
require(to != address(0), "ERC20: transfer to the zero address");
function _transfer(address sender, address recipient, uint256 amount) internal {
require(sender != address(0), "ERC20: transfer from the zero address");
require(recipient != address(0), "ERC20: transfer to the zero address");
_balances[from] = _balances[from].sub(value);
_balances[to] = _balances[to].add(value);
emit Transfer(from, to, value);
_balances[sender] = _balances[sender].sub(amount);
_balances[recipient] = _balances[recipient].add(amount);
emit Transfer(sender, recipient, amount);
}
/**
* @dev Internal function that mints an amount of the token and assigns it to
* an account. This encapsulates the modification of balances such that the
* proper events are emitted.
* @param account The account that will receive the created tokens.
* @param value The amount that will be created.
/** @dev Creates `amount` tokens and assigns them to `account`, increasing
* the total supply.
*
* Emits a `Transfer` event with `from` set to the zero address.
*
* Requirements
*
* - `to` cannot be the zero address.
*/
function _mint(address account, uint256 value) internal {
function _mint(address account, uint256 amount) internal {
require(account != address(0), "ERC20: mint to the zero address");
_totalSupply = _totalSupply.add(value);
_balances[account] = _balances[account].add(value);
emit Transfer(address(0), account, value);
_totalSupply = _totalSupply.add(amount);
_balances[account] = _balances[account].add(amount);
emit Transfer(address(0), account, amount);
}
/**
* @dev Internal function that burns an amount of the token of a given
* account.
* @param account The account whose tokens will be burnt.
* @param value The amount that will be burnt.
/**
* @dev Destoys `amount` tokens from `account`, reducing the
* total supply.
*
* Emits a `Transfer` event with `to` set to the zero address.
*
* Requirements
*
* - `account` cannot be the zero address.
* - `account` must have at least `amount` tokens.
*/
function _burn(address account, uint256 value) internal {
require(account != address(0), "ERC20: burn from the zero address");
@ -163,10 +195,17 @@ contract ERC20 is IERC20 {
}
/**
* @dev Approve an address to spend another addresses' tokens.
* @param owner The address that owns the tokens.
* @param spender The address that will spend the tokens.
* @param value The number of tokens that can be spent.
* @dev Sets `amount` as the allowance of `spender` over the `owner`s tokens.
*
* This is internal function is equivalent to `approve`, and can be used to
* e.g. set automatic allowances for certain subsystems, etc.
*
* Emits an `Approval` event.
*
* Requirements:
*
* - `owner` cannot be the zero address.
* - `spender` cannot be the zero address.
*/
function _approve(address owner, address spender, uint256 value) internal {
require(owner != address(0), "ERC20: approve from the zero address");
@ -177,15 +216,13 @@ contract ERC20 is IERC20 {
}
/**
* @dev Internal function that burns an amount of the token of a given
* account, deducting from the sender's allowance for said account. Uses the
* internal burn function.
* Emits an Approval event (reflecting the reduced allowance).
* @param account The account whose tokens will be burnt.
* @param value The amount that will be burnt.
* @dev Destoys `amount` tokens from `account`.`amount` is then deducted
* from the caller's allowance.
*
* See `_burn` and `_approve`.
*/
function _burnFrom(address account, uint256 value) internal {
_burn(account, value);
_approve(account, msg.sender, _allowances[account][msg.sender].sub(value));
function _burnFrom(address account, uint256 amount) internal {
_burn(account, amount);
_approve(account, msg.sender, _allowances[account][msg.sender].sub(amount));
}
}