WIP: test: initial subxt test

[extraymond]

alternative tests using subxt, currently using raw selector until the ABI are compatible where we can just use contract-transcode. test cases are semantically derived from the original substrate integration tests using polkadot.js.

[extraymond]

Started to use contract-transcode for encoding message selector, which works with the two exception:

1. when using constructor overloading, due to all constructors have the same name, which contract-transcode will only match the first one, currently it'll never reach the second constructor.
2. transcoding U256/I256 won't work. U256 is configured with sp_core::U256 as it's custom transcoder but it won't actually use it since it's using the TypeInfo::type_info() to get the Path, which is all empty for solang runtime types. I256 is unprocessed at all.

[xermicus]

I think this is a great effort overall!

when using constructor overloading, due to all constructors have the same name, which contract-transcode will only match the first one, currently it'll never reach the second constructor.

Options I see so far:

• Introduce a custom attribute to set a name for the constructor (e.g. like the way it is done for selector), and default to new or something else when no overloading is happening and no name is given.
• Mangle the name based by its arguments, would be less work to code up I guess, but ugly from a user perspective

transcoding U256/I256 won't work. U256 is configured with sp_core::U256 as it's custom transcoder but it won't actually use it since it's using the TypeInfo::type_info() to get the Path, which is all empty for solang runtime types. I256 is unprocessed at all.

U256 is not (yet) supported in ink!. The easiest solution would be if we can get it to work by using the U256 path of ethereum-types lib somehow?

[xermicus]

@extraymond it makes me sad that we didn't go forward sooner with this PR, sorry! I really like what you implemented here. In the long run, it would make sense to integrate this with #1061. How-ever, this should not block your nice work here. May I ask you for the favor of merging current main with this again? Then I'd be very happy to give a usual round of review and LGTM!

[extraymond]

@extraymond it makes me sad that we didn't go forward sooner with this PR, sorry! I really like what you implemented here. In the long run, it would make sense to integrate this with #1061. How-ever, this should not block your nice work here. May I ask you for the favor of merging current main with this again? Then I'd be very happy to give a usual round of review and LGTM!

Sure! I'll be on it sometime this week.

[xermicus]

Sure! I'll be on it sometime this week.

Awesome, thanks! While you're on it, can you directly aim for compatibility with pallets contract v0.22.1 (it uses WeightV2)? Not all contracts will work ATM though, as I have to fix some imports first (gonna make a PR for this).

EDIT: https://github.com/hyperledger/solang/pull/1080

[extraymond]

@xermicus @seanyoung Rebased to current master. Some failed tests are ignored as suggested. Looking forward for your review.

[xermicus]

@extraymond FYI the rust source files need a SPDX header, this is why the Lints job failed (unfortunately it'll just time out if there are some headers missing)

[extraymond]

Ah! Got it.

@extraymond FYI the rust source files need a SPDX header, this is why the Lints job failed (unfortunately it'll just time out if there are some headers missing)

Ah got it, I'll fix it later.

[extraymond]

@xermicus I think it would be nice to tap into debug buffer when contract trapped. It's very hard to debug why it's trapped within the test.

[xermicus]

@xermicus I think it would be nice to tap into debug buffer when contract trapped. It's very hard to debug why it's trapped within the test.

I see what you mean; however I think this should ideally be done by contracts pallet (so the runtime executing the contract). In the contract code itself, we have limited control about trapping. We might write into the debug buffer if we know for sure we are going to trap (for example because the compiler inserts a trap manually). However, there are many other cases (OOM, invalid instructions etc) only the runtime knows or has control about.

For this to work we would need to provide the runtime debug info, but for now IIRC the contracts pallet doesn't support this.

[extraymond]

@xermicus I think it would be nice to tap into debug buffer when contract trapped. It's very hard to debug why it's trapped within the test.

I see what you mean; however I think this should ideally be done by contracts pallet (so the runtime executing the contract). In the contract code itself, we have limited control about trapping. We might write into the debug buffer if we know for sure we are going to trap (for example because the compiler inserts a trap manually). However, there are many other cases (OOM, invalid instructions etc) only the runtime knows or has control about.

For this to work we would need to provide the runtime debug info, but for now IIRC the contracts pallet doesn't support this.

Yeah, cargo-contract does it by doing a sequential read call if a first write call failed. Maybe we should revisit it later when we have some shared lib from cargo-contract that we can directly pulled.

[extraymond]

@seanyoung I think one of my forced push for rebase cleared your original change request. I believe I have implemented the suggestion back then.

[xermicus]

Amazing, thank you!

[seanyoung]

@extraymond good stuff, thanks!