chiru-labs / erc721a-upgradeable Goto Github PK

Version 4.x introduces several breaking changes.

Please refer to the documentation for more details.

Trying to use the ERC4907AUpgradeable contract with the ERC721A contract and I'm getting a

TypeError: Overriding function is missing "override" specifier.
  --> erc721a-upgradeable/contracts/extensions/ERC4907AUpgradeable.sol:61:5:
   |
61 |     function userOf(uint256 tokenId) public view virtual returns (address) {
   |     ^ (Relevant source part starts here and spans across multiple lines).
Note: Overridden function is here:
  --> erc721a-upgradeable/contracts/extensions/IERC4907AUpgradeable.sol:42:5:
   |
42 |     function userOf(uint256 tokenId) external view returns (address);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


TypeError: Overriding function is missing "override" specifier.
  --> erc721a-upgradeable/contracts/extensions/ERC4907AUpgradeable.sol:79:5:
   |
79 |     function userExpires(uint256 tokenId) public view virtual returns (uint256) {
   |     ^ (Relevant source part starts here and spans across multiple lines).
Note: Overridden function is here:
  --> erc721a-upgradeable/contracts/extensions/IERC4907AUpgradeable.sol:47:5:
   |
47 |     function userExpires(uint256 tokenId) external view returns (uint256);

Also, likely unrelated, but I'm required to override the supportsInterface function, but am getting a

TypeError: Invalid contract specified in override list: "IERC721AUpgradeable".
  --> contracts/myContract.sol:72:9:
   |
72 |         override(
   |         ^ (Relevant source part starts here and spans across multiple lines).
Note: This contract: 
  --> erc721a-upgradeable/contracts/IERC721AUpgradeable.sol:10:1:
   |
10 | interface IERC721AUpgradeable {
   | ^ (Relevant source part starts here and spans across multiple lines).

On pragma solidity ^0.8.4;

Here's my inheritance list:

contract CurdRouletteTableNft is
    ERC721AUpgradeable,
    Initializable,
    AccessControlUpgradeable,
    ERC721ABurnableUpgradeable,
    ERC721AQueryableUpgradeable,
    ERC4907AUpgradeable,
    UUPSUpgradeable

Happy to make necessary change and post a PR for review

• Issue: Cyclic dependencies in ERC721AUpgradeable.sol and ERC721AStorage.sol cause Hardhat flatten error.
• Error Message:

  Error HH603: Hardhat flatten doesn't support cyclic dependencies.
  For more info go to https://hardhat.org/HH603 or run Hardhat with --show-stack-traces
  

• Version: 4.2.0
• Cyclic Dependencies Code:

  • ERC721AUpgradeable.sol line 8

    import {ERC721AStorage} from './ERC721AStorage.sol';

  • ERC721AStorage.sol line 5

    import {ERC721AUpgradeable} from './ERC721AUpgradeable.sol';

Is this code dependency approach intentional?
Thank you :D

sorry for the question as an "issue", but didn't see another venue for such things. are you planning on publishing 4.0.0 to npm, or should i wait for 4.0.1?

cheers and thanks for your efforts!

I'm using the Diamond standard and it would be useful for me to be able to _mint() from multiple facets.

However, multiple facets cannot inherit from ERC721AUpgradeable because ERC721AUpgradeable has public functions and multiple facets cannot define the same public function.

I propose adding a ERC721AInternal contract that Diamond-ers can inherit from in multiple places. This would not affect anyone else as they could continue inheriting from ERC721AUpgradeable (basically what I'm proposing is a copy-paste).

SolidState takes this approach for their ERC721, so it has been done!

Thanks!

In the most recent update for ERC721A (v3.3.0) the upgradeable version of the contract now has a constructor instead of an initializer function. Was this intended?

In addition the Upgradeable suffix has been removed from the contracts. I believe this may be a mistake.

I think it should be initializerERC721A() in https://github.com/chiru-labs/ERC721A-Upgradeable/blob/main/contracts/ERC721AUpgradeable.sol#L96 instead of onlyInitializingERC721A()

The example code on the README file inherits OwnableUpgradeable.sol from OpenZeppelin. OwnableUpgradeable.sol declares state variables outside Diamond Storage which can lead to storage collision if any other contracts, or inherited contracts declare state variables outside Diamond Storage. The best practice for diamonds is to declare all state variables within AppStorage or Diamond Storage.

SafeOwnable.sol from solidsate-solidity could be used instead, or other implementation.