Solang does not implement address.code

[LucasSte]

This contract works on Solc, but fails on Solang

contract Code {

    function isContract(address account) internal view returns (bool) {
        // This method relies on extcodesize/address.code.length, which returns 0
        // for contracts in construction, since the code is only stored at the end
        // of the constructor execution.

        return account.code.length > 0;
    }

}

The error is the following:

error: 'code' not found
  ┌─ /home/lucas/Documents/solang/examples/array.sol:8:16
  │
8 │         return account.code.length > 0;
  │                ^^^^^^^^^^^^

[oblx]

Same here while compiling an ERC721.

Did you find a workaround @LucasSte ?

[LucasSte]

Same here while compiling an ERC721.

Did you find a workaround @LucasSte ?

We haven't found a solution yet. Can you provide more details on what you're trying to achieve? We are certainly can find a way around.

If you are interesting in creating NFTs for Solana, for instance, you need to use the SPL-token integration and not ERC721. You can find more information about how to use the SPL-token on Solana and Solang here.

[oblx]

Hi and thanks for your answer ! I was dumbly trying to convert an erc721 contract and switch to solana like I was always there. But no, definitely no.

Thanks for the doc, I definitely need more knowledge before deploying on solana :)

[xermicus]

I'm going to pick this up, we need it.

[bkushigian]

@xermicus thanks for linking to this issue! I didn't see it (probably should have dug through the issue tracker before spamming you guys! Sorry, I was in go mode :D)

So I think #1537 is slightly different than this one, though they're obviously related. This issue is that solang's pipeline fails on address.code while my issue is about the parse and resolve component of the pipeline. I think that even if solang can't handle address.code, the AST should still be built and errors should be pushed down the pipeline.

[bkushigian]

I'm coming at this as a client of only parse_and_resolve, I just need an AST (with types, so parsetree is not enough) and I never touch anything else in the pipeline.

[bkushigian]

@xermicus just want to ping you on this. Would it be fair to reopen #1537 since it's a subproblem that could be fixed even if this issue is unfixed? The sema stage should not fail because of an address.code, even if the rest of the pipeline cannot handle it.

[xermicus]

@bkushigian yeah good point, it certainly can be implemented in sema but not in later stages. But let's just keep this issue only, implementing it in sema is part of it anyways :upside_down_face:

[xermicus]

@bkushigian FIY I implemented it for sema in #1549

[bkushigian]

@xermicus thank you!

[xermicus]

Removing from the OZ milestone for Polkadot; OppenZeppelin contracts check the address.code.length to distinguish contract addresses, however on Polkadot we have the is_contract builtin to do the same.