Milestone 1: Ensure Solang works with latest Substrate

[xermicus]

Solang was developed against Substrate v3.0 and older versions of both the npm polkadot api and the contract metadata crate. They need to be updated to the latest versions, and any consequent issues will need to be resolved.

The Substrate integration tests at:
https://github.com/hyperledger-labs/solang/tree/main/integration/substrate
use various polkadot npm libraries, must all be updated to the latest version, and any consequent issues must be resolved. Success for this milestone is simply that the tests are upgraded to the latestversions of all the substrate components and the tests pass, in a pull request to solang repository and any review comments are addressed.

Status

• Update Integration tests
  • Update existing test suite and use up-to-date production substrate node: Update substrate integration test environment #931
  • Fix any remaining regressions
  • Integrate and use subxt for integration tests: test: initial subxt test #990
• Various bug fixes and changes in solang to better align with substrate
  • Substrate: concrete contracts must have public or external functions #999
  • allow constructor names in substrate #1035
  • Fix function calls via contract name #1011
  • Function name mangling #1027
  • Fix anonymous values in return types
  • Update calls to the seal API to reflect latest versions: Update seal calls #1025
    • seal_instantiate
    • seal_terminate
    • seal_call (todo: flags)
    • seal_set_storage
    • seal_clear_storage
    • seal_get_storage
    • seal_tombstone_deposit (gone) Substrate: Remove seal_tombstone_deposit #1022
    • seal_random will be removed, replace it for contract instantiation with new seal_nonce API
  • Implement missing seal API calls (can be done at a later stage)
  • Adapt mappings (and possibly arrays too?)to work with new storage keys
  • Add substrate builtins #1045
• Re-use ink_metadata for ABI generation: Feature ink metadata for substrate #989
  • Allow scale-info to be used at runtime
  • Allow ink_metadata to be used at runtime
  • Since the ink! storage refactor, ink_metadata requires nightly rust. We must be able to compile with stable rust (without RUSTC_BOOTSTRAP). Potential fix

[erasmus]

@xermicus thank you for the work here. Do you have an estimate of when it would be finished?

[xermicus]

@xermicus thank you for the work here. Do you have an estimate of when it would be finished?

Very welcome. Currently blocked until the ink! v4 beta release, which will contain the necessary code to make this work. It is just around the corner. Based of that I expect #989 to land in our master probably next week. However, depending on your needs, you can already build solang using the branch from PR #988, to try it out right now. There might be minor changes to it but overall it already works.

[erasmus]

@xermicus great news, we will check it out 🙏

[xermicus]

@erasmus FYI #988 got merged into main. For contract development you should be good with the following:

1. Compile solang yourself using our main branch
2. Substrate contracts node releases v0.19 - v.0.21 are compatible

Please let me know whether this works for you or if you run into any problems.

There are very few broken things remaining now that I know of. The main thing is #970, so don't expect indexed (topic) events to work at all. Once this is done, we will make another solang release (probably next week) that works with the contract node versions I mentioned above and can be used until ink! v4 is released (this will only be next year and solang is expected to be fully compatible by then).

[athei]

Why is Solang not compatible with the newest contracts node (´0.22.1`)? Is this about stabilized functions changing its module (we should really stop doing that)?

[RustNinja]

I have a solidity smart contract that I compile using Solang to substrate wasm.

contract Pool {
address xxx;
constructor(address _test){
  xxx = _test;
}

function callFoo(address _test) external returns (bool){
  _test.call(abi.encodeWithSignature("flip()"));
  return true;
}

But I received the error trying deploy the contract using polkadot js org

I found the notes according to solang current stage

Solang works with Parity Substrate 3.0. Note that for recent Substrate Version, cross-contract calls as well as using address type as function argument or return values ARE NOT SUPPORTED. We are currently working on fixing any regressions.

https://solang.readthedocs.io/en/latest/targets/substrate.html

Does solang already support cross-contract calls as well as using address type as function argument or return values?
@athei @xermicus

[xermicus]

Is this about stabilized functions changing

@athei I had this PR that went into v0.22.1 at the back of my mind and so it is potentially breaking (solang currently links some __unstable__), however I didn't had the chance to check it in detail. So for one our CI currently uses v0.19, but 0.20 and 0.21 also pass the integration tests. And since the front end does not yet support v0.22.1 I guess it would not make sense to use that for anyone wanting to try it out already. But I'll look into supporting v0.22.1 soon.

@cr4pt0 are you using solang based on our main branch? Your example works fine (metadata-wise) but you need to compile solang from our main branch yourself as the fix for this issue is not yet released see my comment above.

[RustNinja]

Compile solang yourself using main branch means?
https://solang.readthedocs.io/en/latest/installing.html#step-2-build-solang

But how to build for substrate?
https://solang.readthedocs.io/en/latest/installing.html#building-llvm-from-source
This example for solana

[xermicus]

@cr4pt0 yes you should do Step 2: Build Solang. However you don't need to build from source LLVM yourself, you can just use the pre-built binaries mentioned in Step 1.

[athei]

@athei I had this PR that went into v0.22.1 at the back of my mind and so it is potentially breaking (solang currently links some __unstable__), however I didn't had the chance to check it in detail.

You are right. It is annoying that functions change modules when they are stabilized. I wanna change that so that they will be added in the module they will eventually end up in if they get stabilized. They are just not there if the unstable-interface feature is not supplied.

[xermicus]

@erasmus FIY we recently released v0.2.0 which contains these fixes and also supports the latest substrate contract node v0.22.1.

[RustNinja]

@xermicus Amazing!! Thank you so much!