Implement Solang Projects

[xermicus]

Problem statement

It came to our attention that the compiler needs a lot of information that is not available in the source code. E.g.:

• Contract authors
• Contract version
• Target configuration

This is getting cumbersome. The idea we had is to have a simple "project configuration" TOML file for solang, similar to what the Cargo.toml file does. It could even be name Solang.toml. Next to what we require to compile the contract it could contain some more information, e.g. which version of solang is required, license, ...

Deliverables

• Implement a solang new command which automatically creates a project in the specified folder:
  • There should be a "Solang.toml" file with sensible defaults
  • There should be a flipper contract
  • The new command should already support some flags regarding the target configuration, e.g. solana or substrate
• Regarding the target configuration, it should be it's own section. For substrate:
  • Should be able to cover value and address configuration (as it is currently provided by our CLI)
  • Users should also be able to specify it on a high level. E.g. "pallet-contract with version v0.22.1", "shiden parachain" or "substrate version X.Y.Z", without having to worry about the low level details and implications. The compiler should then produce contracts compatible with what the user specifies (and detect not supported / invalid configurations).
• Adapt the compiler to respect all this new information.
• Add some CI tests to check whether this actually works. E.g. create a new project, specify the target, compile and test it against the expected runtime node.

[seanyoung]

This should also include:

• List of directories to look for imports solang --importpath
• Import maps, like solang --importmap
• Math overflow enabled/not enabled

[seanyoung]

Solang.toml is not a bad idea. Foundry uses foundry.toml, we should also look at what Foundy/Truffle/Anvil offer. Ideally we would have some more subcommands like solang test at some point in the future.

[xermicus]

Another configuration possibility: Initial and max heap size

[salaheldinsoliman]

Regarding the substrate target configuration, @xermicus and I reached the conclusion that it would be best to leave the current configuration options as is. What a user currently can do is specify address-length and value-length in bytes and the compiler would generate wasm code accordingly.

The reason we reached that conclusion is that all parachains we know of using the ink contracts pallet use the same configurations of AccountID32 and balance = u128. Here are some famous examples:

Acala: source code defining address length balance as u128 (16 bytes)

Astar: address length Balance length

Phala: Address length Balance length

More than the address length and value length, we also thought of another configuration: hash length. After a bit of research, we also found that to be constant across all chains as defined in contract_metadata