Warning: Unreachable code on _checkOnERC721Received when overriding the transferFrom function.

💻 Environment

• Compiler version: 0.8.20
• Target EVM version (as per compiler settings): Paris
• Framework/IDE (e.g. Truffle or Remix): Hardhat
• EVM execution environment / backend / blockchain client: Terminal running npx hardhat clean & npx hardhat compile
• Operating system: Mac OS Sonoma 14.5
• "dependencies": {
  "@openzeppelin/contracts": "^5.0.2",
  "@openzeppelin/contracts-upgradeable": "^5.0.2"
  },

📝 Details
Note: a minor warning has appeared for the first time after compiling.

I’m using @openzeppelin/contracts-upgradeable and trying to override the transferFrom function. When I run npx hardhat clean & npx hardhat compile, I’m encountering a warning:

Warning: Unreachable code.
   --> @openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol:184:9:
    |
184 |         _checkOnERC721Received(from, to, tokenId, data);

It appears that _checkOnERC721Received isn’t being called on line 184, but if I swap the order and place _checkOnERC721Received first like the following code block, the warning disappears. I’m curious if _checkOnERC721Received should be called before transferFrom?

function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory data) public virtual {
    _checkOnERC721Received(from, to, tokenId, data);        
    transferFrom(from, to, tokenId);
}

🔢 Code to reproduce bug

Here’s my overridden transferFrom function:

function transferFrom(
    address,
    address,
    uint256
) public pure override(ERC721Upgradeable, IERC721) {
    revert("Use customTransferFrom function instead");
}

Could you help clarify if _checkOnERC721Received should be called before transferFrom to avoid the warning when overriding the function?

Start with contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol around line 184 and reproduce the warning with the shown transferFrom override using Hardhat. Trace the safe-transfer path and compiler behavior, then document whether the warning is expected and what the supported resolution is; done means the warning’s cause and call ordering are clearly explained.