bump version to v0.6.0 (#538)

README.md

@@ -53,7 +53,7 @@ Installing directly the `main` branch may contain incomplete or breaking impleme
 
 ### Use a basic preset
 
-Presets are ready-to-use contracts that you can deploy right away. They also serve as examples of how to use library modules. [Read more about presets](https://docs.openzeppelin.com/contracts-cairo/0.5.1/extensibility#presets).
+Presets are ready-to-use contracts that you can deploy right away. They also serve as examples of how to use library modules. [Read more about presets](https://docs.openzeppelin.com/contracts-cairo/0.6.0/extensibility#presets).
 
 ```cairo
 // contracts/MyToken.cairo
@@ -84,11 +84,11 @@ nile compile
 nile deploy MyToken <name> <symbol> <decimals> <initial_supply> <recipient> --alias my_token
 ```
 
-> Note that `<initial_supply>` is expected to be two integers i.e. `1` `0`. See [Uint256](https://docs.openzeppelin.com/contracts-cairo/0.5.1/utilities#uint256) for more information.
+> Note that `<initial_supply>` is expected to be two integers i.e. `1` `0`. See [Uint256](https://docs.openzeppelin.com/contracts-cairo/0.6.0/utilities#uint256) for more information.
 
 ### Write a custom contract using library modules
 
-[Read more about libraries](https://docs.openzeppelin.com/contracts-cairo/0.5.1/extensibility#libraries).
+[Read more about libraries](https://docs.openzeppelin.com/contracts-cairo/0.6.0/extensibility#libraries).
 
 ```cairo
 %lang starknet
@@ -115,14 +115,14 @@ func transfer{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
 
 Check out the [full documentation site](https://docs.openzeppelin.com/contracts-cairo)! Featuring:
 
-- [Accounts](https://docs.openzeppelin.com/contracts-cairo/0.5.1/accounts)
-- [ERC20](https://docs.openzeppelin.com/contracts-cairo/0.5.1/erc20)
-- [ERC721](https://docs.openzeppelin.com/contracts-cairo/0.5.1/erc721)
-- [ERC1155](https://docs.openzeppelin.com/contracts-cairo/0.5.1/erc1155)
-- [Contract extensibility pattern](https://docs.openzeppelin.com/contracts-cairo/0.5.1/extensibility)
-- [Proxies and upgrades](https://docs.openzeppelin.com/contracts-cairo/0.5.1/proxies)
-- [Security](https://docs.openzeppelin.com/contracts-cairo/0.5.1/security)
-- [Utilities](https://docs.openzeppelin.com/contracts-cairo/0.5.1/utilities)
+- [Accounts](https://docs.openzeppelin.com/contracts-cairo/0.6.0/accounts)
+- [ERC20](https://docs.openzeppelin.com/contracts-cairo/0.6.0/erc20)
+- [ERC721](https://docs.openzeppelin.com/contracts-cairo/0.6.0/erc721)
+- [ERC1155](https://docs.openzeppelin.com/contracts-cairo/0.6.0/erc1155)
+- [Contract extensibility pattern](https://docs.openzeppelin.com/contracts-cairo/0.6.0/extensibility)
+- [Proxies and upgrades](https://docs.openzeppelin.com/contracts-cairo/0.6.0/proxies)
+- [Security](https://docs.openzeppelin.com/contracts-cairo/0.6.0/security)
+- [Utilities](https://docs.openzeppelin.com/contracts-cairo/0.6.0/utilities)
 
 ### Cairo
 
@@ -262,7 +262,7 @@ def foo_factory():
     return cached_foo
 ```
 
-See [Memoization](https://docs.openzeppelin.com/contracts-cairo/0.5.1/utilities#memoization) in the Utilities documentation for a more thorough example on caching contracts.
+See [Memoization](https://docs.openzeppelin.com/contracts-cairo/0.6.0/utilities#memoization) in the Utilities documentation for a more thorough example on caching contracts.
 
 > Note that this does not apply for stateless libraries such as SafeMath.
 

docs/antora.yml

@@ -1,5 +1,5 @@
 name: contracts-cairo
 title: Contracts for Cairo
-version: 0.5.1
+version: 0.6.0
 nav:
   - modules/ROOT/nav.adoc

docs/modules/ROOT/pages/access.adoc

@@ -1,4 +1,4 @@
-:ownable-cairo: link:https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/access/ownable/library.cairo[Ownable]
+:ownable-cairo: link:https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/access/ownable/library.cairo[Ownable]
 
 :extensibility-pattern: xref:extensibility.adoc#the_pattern
 
@@ -200,7 +200,7 @@ Most software uses access control systems that are role-based: some users are re
 
 For each role that you want to define, you will create a new _role identifier_ that is used to grant, revoke, and check if an account has that role (see <<creating_role_identifiers,Creating role identifiers>> for information on creating identifiers).
 
-Here's a simple example of implementing `AccessControl` on a portion of an link:https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc20/presets/ERC20.cairo[ERC20 token contract] which defines and sets the 'minter' role:
+Here's a simple example of implementing `AccessControl` on a portion of an link:https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc20/presets/ERC20.cairo[ERC20 token contract] which defines and sets the 'minter' role:
 
 [,cairo]
 ----
@@ -350,7 +350,7 @@ However, because those roles' admin role is the default admin role, and that rol
 Dynamic role allocation is often a desirable property, for example in systems where trust in a participant may vary over time.
 It can also be used to support use cases such as https://en.wikipedia.org/wiki/Know_your_customer[KYC], where the list of role-bearers may not be known up-front, or may be prohibitively expensive to include in a single transaction.
 
-The following example uses the link:https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/tests/mocks/AccessControl.cairo[AccessControl mock contract] which exposes the role management functions.
+The following example uses the link:https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/tests/mocks/AccessControl.cairo[AccessControl mock contract] which exposes the role management functions.
 To grant and revoke roles in Python, for example:
 
 [,python]
@@ -388,7 +388,7 @@ bytes32 public constant SOME_ROLE = keccak256("SOME_ROLE")
 These identifiers take up 32 bytes (256 bits).
 
 Cairo field elements store a maximum of 252 bits.
-Even further, a declared _constant_ field element in a StarkNet contract stores even less (see https://github.com/starkware-libs/cairo-lang/blob/release-v0.5.1/src/starkware/cairo/lang/cairo_constants.py#L1[cairo_constants]).
+Even further, a declared _constant_ field element in a StarkNet contract stores even less (see https://github.com/starkware-libs/cairo-lang/blob/release-v0.6.0/src/starkware/cairo/lang/cairo_constants.py#L1[cairo_constants]).
 With this discrepancy, this library maintains an agnostic stance on how contracts should create identifiers.
 Some ideas to consider:
 

docs/modules/ROOT/pages/accounts.adoc

@@ -1,4 +1,4 @@
-:test-signers: https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/tests/signers.py
+:test-signers: https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/tests/signers.py
 
 = Accounts
 
@@ -148,7 +148,7 @@ Since `address` will ultimately depend on the `class_hash` and `calldata`, it's
 
 == Standard interface
 
-The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/account/IAccount.cairo[`IAccount.cairo`] contract interface contains the standard account interface proposed in https://github.com/OpenZeppelin/cairo-contracts/discussions/41[#41] and adopted by OpenZeppelin and Argent.
+The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/account/IAccount.cairo[`IAccount.cairo`] contract interface contains the standard account interface proposed in https://github.com/OpenZeppelin/cairo-contracts/discussions/41[#41] and adopted by OpenZeppelin and Argent.
 It implements https://eips.ethereum.org/EIPS/eip-1271[EIP-1271] and it is agnostic of signature validation. Further, nonce management is handled on the protocol level.
 
 NOTE: `\\__validate_deploy__` is not part of the interface since it's only callable by the protocol. Also contracts don't need to implement it to be considered accounts.
@@ -582,11 +582,11 @@ Each preset differs on the signature type being used by the Account.
 
 === Account
 
-The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/account/presets/Account.cairo[`Account`] preset uses StarkNet keys to validate transactions.
+The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/account/presets/Account.cairo[`Account`] preset uses StarkNet keys to validate transactions.
 
 === Eth Account
 
-The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/account/presets/EthAccount.cairo[`EthAccount`] preset supports Ethereum addresses, validating transactions with secp256k1 keys.
+The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/account/presets/EthAccount.cairo[`EthAccount`] preset supports Ethereum addresses, validating transactions with secp256k1 keys.
 
 == Account introspection with ERC165
 

docs/modules/ROOT/pages/erc1155.adoc

@@ -214,7 +214,7 @@ Otherwise, transfer functions should fail.
 
 === ERC1155MintableBurnable
 
-The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc1155/presets/ERC1155MintableBurnable.cairo[`ERC1155MintableBurnable`] preset offers a quick and easy setup for creating ERC1155 tokens. Its constructor takes three arguments: `name`, `symbol`, and an `owner` address which will be capable of minting tokens.
+The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc1155/presets/ERC1155MintableBurnable.cairo[`ERC1155MintableBurnable`] preset offers a quick and easy setup for creating ERC1155 tokens. Its constructor takes three arguments: `name`, `symbol`, and an `owner` address which will be capable of minting tokens.
 
 == Utilities
 

docs/modules/ROOT/pages/erc20.adoc

@@ -134,7 +134,7 @@ await signer.send_transaction(account, erc20.contract_address, 'transfer', [reci
 ERC20 contracts can be extended by following the xref:extensibility.adoc#the_pattern[extensibility pattern].
 The basic idea behind integrating the pattern is to import the requisite ERC20 methods from the ERC20 library and incorporate the extended logic thereafter.
 For example, let's say you wanted to implement a pausing mechanism.
-The contract should first import the ERC20 methods and the extended logic from the https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/security/pausable/library.cairo[Pausable library] i.e. `Pausable.pause`, `Pausable.unpause`.
+The contract should first import the ERC20 methods and the extended logic from the https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/security/pausable/library.cairo[Pausable library] i.e. `Pausable.pause`, `Pausable.unpause`.
 Next, the contract should expose the methods with the extended logic therein like this:
 
 [,cairo]
@@ -166,21 +166,21 @@ Each preset mints an initial supply which is especially necessary for presets th
 
 === ERC20 (basic)
 
-The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc20/presets/ERC20.cairo[`ERC20`] preset offers a quick and easy setup for deploying a basic ERC20 token.
+The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc20/presets/ERC20.cairo[`ERC20`] preset offers a quick and easy setup for deploying a basic ERC20 token.
 
 === ERC20Mintable
 
-The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc20/presets/ERC20Mintable.cairo[`ERC20Mintable`] preset allows the contract owner to mint new tokens.
+The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc20/presets/ERC20Mintable.cairo[`ERC20Mintable`] preset allows the contract owner to mint new tokens.
 
 === ERC20Pausable
 
-The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc20/presets/ERC20Pausable.cairo[`ERC20Pausable`] preset allows the contract owner to pause/unpause all state-modifying methods i.e.
+The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc20/presets/ERC20Pausable.cairo[`ERC20Pausable`] preset allows the contract owner to pause/unpause all state-modifying methods i.e.
 `transfer`, `approve`, etc.
 This preset proves useful for scenarios such as preventing trades until the end of an evaluation period and having an emergency switch for freezing all token transfers in the event of a large bug.
 
 === ERC20Upgradeable
 
-The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc20/presets/ERC20Upgradeable.cairo[`ERC20Upgradeable`] preset allows the contract owner to upgrade a contract by deploying a new ERC20 implementation contract while also maintaining the contract's state.
+The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc20/presets/ERC20Upgradeable.cairo[`ERC20Upgradeable`] preset allows the contract owner to upgrade a contract by deploying a new ERC20 implementation contract while also maintaining the contract's state.
 This preset proves useful for scenarios such as eliminating bugs and adding new features.
 For more on upgradeability, see xref:proxies.adoc#contract_upgrades[Contract upgrades].
 

docs/modules/ROOT/pages/erc721.adoc

@@ -114,7 +114,7 @@ To be as close as possible to the standard, it accepts a dynamic array of felts.
 In Cairo, arrays are expressed with the array length preceding the actual array;
 hence, the method accepts `data_len` and `data` respectively as types `felt` and `felt*`.
 * `ERC165.register_interface` allows contracts to set and communicate which interfaces they support.
-This follows OpenZeppelin's https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v0.5.1/contracts/utils/introspection/ERC165Storage.sol[ERC165Storage].
+This follows OpenZeppelin's https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v0.6.0/contracts/utils/introspection/ERC165Storage.sol[ERC165Storage].
 * `IERC721Receiver` compliant contracts (`ERC721Holder`) return a hardcoded selector id according to EVM selectors, since selectors are calculated differently in Cairo.
 This is in line with the ERC165 interfaces design choice towards EVM compatibility.
 See the xref:introspection.adoc[Introspection docs] for more info.
@@ -261,7 +261,7 @@ Instead, the interface IDs are hardcoded from their EVM calculations.
 On the EVM, the interface ID is calculated from the selector's first four bytes of the hash of the function's signature while Cairo selectors are 252 bytes long.
 Due to this difference, hardcoding EVM's already-calculated interface IDs is the most consistent approach to both follow the EIP165 standard and EVM compatibility.
 
-Further, this implementation stores supported interfaces in a mapping (similar to OpenZeppelin's https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v0.5.1/contracts/utils/introspection/ERC165Storage.sol[ERC165Storage]).
+Further, this implementation stores supported interfaces in a mapping (similar to OpenZeppelin's https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v0.6.0/contracts/utils/introspection/ERC165Storage.sol[ERC165Storage]).
 
 === Ready-to-Use Presets
 

docs/modules/ROOT/pages/extensibility.adoc

@@ -81,15 +81,15 @@ They can be deployed as-is or used as templates for customization.
 
 Some presets are:
 
-* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/account/presets/Account.cairo[Account]
-* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/tests/mocks/ERC165.cairo[ERC165]
-* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc20/presets/ERC20Mintable.cairo[ERC20Mintable]
-* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc20/presets/ERC20Pausable.cairo[ERC20Pausable]
-* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc20/presets/ERC20Upgradeable.cairo[ERC20Upgradeable]
-* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc20/presets/ERC20.cairo[ERC20]
-* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc721/presets/ERC721MintableBurnable.cairo[ERC721MintableBurnable]
-* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc721/presets/ERC721MintablePausable.cairo[ERC721MintablePausable]
-* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/token/erc721/enumerable/presets/ERC721EnumerableMintableBurnable.cairo[ERC721EnumerableMintableBurnable]
+* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/account/presets/Account.cairo[Account]
+* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/tests/mocks/ERC165.cairo[ERC165]
+* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc20/presets/ERC20Mintable.cairo[ERC20Mintable]
+* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc20/presets/ERC20Pausable.cairo[ERC20Pausable]
+* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc20/presets/ERC20Upgradeable.cairo[ERC20Upgradeable]
+* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc20/presets/ERC20.cairo[ERC20]
+* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc721/presets/ERC721MintableBurnable.cairo[ERC721MintableBurnable]
+* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc721/presets/ERC721MintablePausable.cairo[ERC721MintablePausable]
+* https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/token/erc721/enumerable/presets/ERC721EnumerableMintableBurnable.cairo[ERC721EnumerableMintableBurnable]
 
 In previous versions of Cairo importing any function from a module would automatically import all `@external` functions. We used to leverage this behavior to just import the constructor of the preset contract to load it.
 Since Cairo v0.10, however, contracts that utilize the preset contracts should import all of the exposed functions from it. For example:

docs/modules/ROOT/pages/introspection.adoc

@@ -27,7 +27,7 @@ There may even not be any direct calls to them!
 ERC20 tokens may be sent to a contract that lacks a way to transfer them out of it, locking them forever).
 In these cases, a contract declaring its interface can be very helpful in preventing errors.
 
-It should be noted that the https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/utils/constants/library.cairo[constants library] includes constant variables referencing all of the interface ids used in these contracts.
+It should be noted that the https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/utils/constants/library.cairo[constants library] includes constant variables referencing all of the interface ids used in these contracts.
 This allows for more legible code i.e.
 using `IERC165_ID` instead of `0x01ffc9a7`.
 
@@ -76,7 +76,7 @@ func check_support{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_p
 ----
 
 NOTE: `supportsInterface` is camelCased because it is an exposed contract method as part of ERC165's interface.
-This differs from library methods (such as `supports_interface` from the https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.5.1/src/openzeppelin/introspection/erc165/library.cairo[ERC165 library]) which are snake_cased and not exposed.
+This differs from library methods (such as `supports_interface` from the https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.0/src/openzeppelin/introspection/erc165/library.cairo[ERC165 library]) which are snake_cased and not exposed.
 See the xref:extensibility.adoc#function_names_and_coding_style[Function names and coding style] for more details.
 
 === IERC165