use-ink / cargo-contract Goto Github PK

As a follow up to #33 we should investigate the possibility of generating the files in .ink/abi_gen.

• Generate files currently in .ink/abi_gen in template
  • Would require determining the contract type for main.rs: let abi = <contract::{{camel_name}} as ink_lang::GenerateAbi>::generate_abi(); which will not neessarily be the same name as the contract package.
• Add or amend workspace section with ink_abi as a member
• Check build caching works

Repository's settings have been updated in the following ways:

• protected branch set to "master"
• status checks must pass in order for a pull request to be merged

other settings:

branch: "master",
required_status_checks: {
  contexts: ["cla"],
  strict: false
},
enforce_admins: true,
required_pull_request_reviews: null,
restrictions: null

For more information, see octokit documentation

This issue was created for informational purposes only. Feel free to close this issue at any time.

Regards,
cla-bot-2020

While following the Smart Contracts workshop I face the following error when running RUST_BACKTRACE=1 cargo contract build (I'm facing this problem while working on the tutorials "Building Your Contract":

 [1/3] Building cargo project
error: failed to write /var/folders/v4/p3y4lz2d6zs45hb1pc1z3q900000gn/T/cargo-xbuildGeYIeJ/Cargo.lock

Caused by:
  failed to open: /var/folders/v4/p3y4lz2d6zs45hb1pc1z3q900000gn/T/cargo-xbuildGeYIeJ/Cargo.lock

Caused by:
  Permission denied (os error 13)
ERROR: Building with xbuild

Caused by:
    `"/nix/store/b8k3sydpfdwkpw2ywbydw8j478p0dz6a-rust/bin/cargo" "rustc" "-p" "alloc" "--release" "--manifest-path" "/var/folders/v4/p3y4lz2d6zs45hb1pc1z3q900000gn/T/cargo-xbuildGeYIeJ/Cargo.toml" "--target" "wasm32-unknown-unknown" "--" "-Z" "force-unstable-if-unmarked"` failed with exit code: Some(101)

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>

I'm running this on Mac OS Catalina 0.15.7 (19H2).

As you can see from the logs pasted above I'm using Nix as my package manager. My shell.nix file is an almost 1:1 copy of Substrates nix.shell file and looks like this:

let
 moz_overlay = import (builtins.fetchTarball https://github.com/mozilla/nixpkgs-mozilla/archive/master.tar.gz);
  nixpkgs = import <nixpkgs> { overlays = [ moz_overlay ]; };
  rust-nightly = with nixpkgs; ((rustChannelOf { date = "2020-10-06"; channel = "nightly"; }).rust.override {
    extensions = [ "rust-src" ];
    targets = [ "wasm32-unknown-unknown" ];
  });
in
with nixpkgs; pkgs.mkShell {
  buildInputs = [
    clang
    cmake
    pkg-config
    rust-nightly
  ] ++ stdenv.lib.optionals stdenv.isDarwin [
    darwin.apple_sdk.frameworks.Security
  ];

  LIBCLANG_PATH = "${llvmPackages.libclang}/lib";
  PROTOC = "${protobuf}/bin/protoc";
  ROCKSDB_LIB_DIR = "${rocksdb}/lib";
}

Let me know if you need anything else and thanks in advance!

When the --verbose flag is passed, the various config settings e.g. [profile.release] which are used should be displayed.

This will allow troubleshooting to see which values are actually used, since they can be a mix of user supplied settings and defaults from cargo-contract

Play around with these suggestions from @Robbepop to achieve the smallest possible binary size:

--converge
--always-inline-max-function-size
--ignore-implicit-traps
--low-memory-unused
--noAssert
-O3z instead of -O3 or -Oz

Used command: cargo install --git https://github.com/paritytech/cargo-contract --force

Currently, the incremental build of metadata has some initial overhead even if no changes at all where made to the project. This seems to be rooted in the fact that on every metadata build the crates index is updated and the project is relinked in release mode:

[1/5] Building cargo project
    Finished release [optimized] target(s) in 0.13s
 [2/5] Post processing wasm file
 [3/5] Optimizing wasm file
 [4/5] Generating metadata
    Updating crates.io index
   Compiling metadata-gen v0.1.0 (/var/folders/8g/_rkmq65n0qnf70c41xvp174h0000gn/T/cargo-contract_XrbNqZ/.ink/metadata_gen)
    Finished release [optimized] target(s) in 1.96s
     Running `target/release/metadata-gen`
 [5/5] Generating bundle

The reason for that is unclear but I suspect that this temporary project is created anew every time the metadata is build. I therefore propose the following two changes to speed this up:

• Do not override the metadata project every time but rather keep in in place and "rsync" with the template, instead
• Build the metadata-gen without optimizations and debug info. I suspect that the build time will outweigh the running time of the project.

The second item is more controversial. It needs some benchmarking before switching.

i have followed the contract workshop.
i build the contract with cargo +nightly-2020-08-23, it gives a warning of wasm-opt not found.
when i deploy it throws extrinsic error.
also in the console it says abi is outdated and i think i have to update ink! but dont know how.

PS C:\Users\hp\desktop\generalized-dex\flipper> cargo +nightly-2020-08-23 contract build
[1/4] Collecting crate metadata
[2/4] Building cargo project
Finished release [optimized] target(s) in 0.31s
[3/4] Post processing wasm file
[4/4] Optimizing wasm file
wasm-opt is not installed. Install this tool on your system in order to
reduce the size of your contract's Wasm binary.
See https://github.com/WebAssembly/binaryen#tools

Your contract is ready. You can find it here:
C:\Users\hp\desktop\generalized-dex\flipper\target\flipper.wasm

when i install wasm-opt using npm it says:

PS C:\Users\hp\desktop\generalized-dex\flipper> cargo +nightly-2020-08-23 contract build
[1/4] Collecting crate metadata
[2/4] Building cargo project
Finished release [optimized] target(s) in 0.42s
[3/4] Post processing wasm file
[4/4] Optimizing wasm file
ERROR: The system cannot find the file specified. (os error 2)

After running cargo contract generate-metadata I am getting this error

error[E0599]: no method named `sign` found for struct `ed25519_dalek::Keypair` in the current scope
   --> /Users/satyamagrawal/.cargo/git/checkouts/substrate-7e08433d4c370a21/b161460/primitives/core/src/ed25519.rs:497:18
    |
497 |         let r = self.0.sign(message).to_bytes();
    |                        ^^^^ method not found in `ed25519_dalek::Keypair`
    |
    = help: items from traits can only be used if the trait is in scope
    = note: the following trait is implemented but not in scope; perhaps add a `use` for it:
            `use ed25519_dalek::Signer;`

error[E0599]: no function or associated item named `from_bytes` found for struct `ed25519_dalek::Signature` in the current scope
   --> /Users/satyamagrawal/.cargo/git/checkouts/substrate-7e08433d4c370a21/b161460/primitives/core/src/ed25519.rs:516:45
    |
516 |         let sig = match ed25519_dalek::Signature::from_bytes(sig) {
    |                                                   ^^^^^^^^^^
    |                                                   |
    |                                                   function or associated item not found in `ed25519_dalek::Signature`
    |                                                   help: there is an associated function with a similar name: `to_bytes`
    |
    = help: items from traits can only be used if the trait is in scope
    = note: the following trait is implemented but not in scope; perhaps add a `use` for it:
            `use ed25519_dalek::ed25519::signature::Signature;`

error[E0599]: no method named `verify` found for struct `ed25519_dalek::PublicKey` in the current scope
   --> /Users/satyamagrawal/.cargo/git/checkouts/substrate-7e08433d4c370a21/b161460/primitives/core/src/ed25519.rs:521:20
    |
521 |         match public_key.verify(message.as_ref(), &sig) {
    |                          ^^^^^^ this is an associated function, not a method
    |
    = note: found the following associated functions; to be used as methods, functions must have a `self` parameter
note: the candidate is defined in the trait `crypto::Pair`
   --> /Users/satyamagrawal/.cargo/git/checkouts/substrate-7e08433d4c370a21/b161460/primitives/core/src/crypto.rs:821:2
    |
821 |     fn verify<M: AsRef<[u8]>>(sig: &Self::Signature, message: M, pubkey: &Self::Public) -> bool;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = help: items from traits can only be used if the trait is in scope
    = note: the following trait is implemented but not in scope; perhaps add a `use` for it:
            `use ed25519_dalek::Verifier;`
help: use associated function syntax instead
    |
521 |         match ed25519_dalek::PublicKey::verify(message.as_ref(), &sig) {
    |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: disambiguate the associated function for the candidate
    |
521 |         match crypto::Pair::verify(public_key, message.as_ref(), &sig) {
    |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 3 previous errors

For more information about this error, try `rustc --explain E0599`.
error: could not compile `sp-core`.

but cargo contract build works fine.

Code - https://github.com/PolymathNetwork/Polymesh/blob/MESH-1133/examples-se/contracts/examples/RuntimeInteraction/lib.rs
cargo-contract version - v0.6.1
ink! version - v2.1.0
substrate version - rc4

As a follow up to #33, which enables amending the Cargo.toml, we could add the following section if it is not present:

[profile.release]
panic = "abort"
lto = true
opt-level = "z"
overflow-checks = true

These are the default optimal settings for contract binary size. However if any of these settings are already defined in the Cargo.toml, then those values should be used instead of these defaults. Potentially the user could be warned if using a non-optimal setting.

After merging use-ink/ink#312 ink! smart contracts will suffer from bloated Wasm binaries due to missing optimizations (or bugs?) between Rust and Wasm translation.

These cause a 0x00 16kB buffer to not be removed from the Wasm binary.
However, Binaryen's wasm-opt with -O3 (or even -O2) can easily do this among other neat optimization routines.

Some contracts have been shown to have a reduced Wasm binary size from 27kB down to 9kB just through using wasm-opt.

The cargo contract build process should include wasm-opt by default, however, if wasm-opt does not exist on the user machine it should simply avoid using it (as it is been done today) and print the user a warning that the resulting Wasm binary might not be optimal and refer the user to install the wasm-opt tool.

When interacting with a contract on chain (with the instantiate and call commands), the code hash in the metadata should be used to verify that the metadata is valid for the target contract.

Steps:

• Calculate the storage key for the contract code (requires at least the account which deployed the contract, needs investigation)
• Download the code blob, fetching from storage via rpc.
• verify blake2_256(code_blob) == metadata.source.hash

Note: The hash of the raw code blob is different to the code_hash on chain because that is concatenated with account used to deploy the code, which is not known at compile time

Repository's settings have been updated in the following ways:

• protected branch set to "master"
• status checks must pass in order for a pull request to be merged

other settings:

branch: "master",
required_status_checks: {
  contexts: ["cla"],
  strict: false
},
enforce_admins: true,
required_pull_request_reviews: null,
restrictions: null

For more information, see octokit documentation

This issue was created for informational purposes only. Feel free to close this issue at any time.

Regards,
cla-bot-2020

When I'm using 0.7.0 installing by cargo install --git https://github.com/paritytech/cargo-contract cargo-contract --force

Apparently it needs to add empty [workspace] to substrate/flipper/Cargo.toml and it looks like works.

Similar to cargo build --workspace: would build all contracts in the workspace (see https://github.com/paritytech/ink/tree/master/examples/delegator).

Should be possible with functionality added in #33.

I think "cargo contract new" should only allow alphabets , dash('-') and numbers.

when I run this in Desktop,

Desktop % cargo contract new ../xxx
	Created contract ../xxx

directory "xxx" is created in home directory.

Desktop % cd ../xxx
xxx %

when I try to build from here,

cargo contract build
 [1/4] Collecting crate metadata
error: Error during execution of `cargo metadata`: error: failed to parse manifest at `/Users/xf9x/xxx/Cargo.toml`

Caused by:
  Invalid character `.` in package name: `../xxx`

build fails.

This is a contender issue for: #22

It solves the same problems but with a different tool. For more details visit the linked issue.
Instead of invoking Cargo in order to build ink! smart contracts we should instead build them using Xargo (https://crates.io/crates/xargo).

This requires another Xargo.toml in the contract's root directory with the following contents:

[target.wasm32-unknown-unknown.dependencies]
core = {default-features=false, features=["panic_immediate_abort"]}
std = {default-features=false, features=["panic_immediate_abort"]}
alloc = {}

Also we have to remove the contents of the .cargo/config file to not override Xargo settings: (We demonstrate this here by simply commenting the line out.)

[target.wasm32-unknown-unknown]
rustflags = [
#	"-C", "link-args=-z stack-size=65536 --import-memory"
]

Another obstacle is that currently Cargo (or rustc) overrides profile settings given in Cargo.toml when rlib is specified as in:

[lib]
name = "erc20"
crate-type = [
	# Used for normal contract Wasm blobs.
	"cdylib",
	# Used for ABI generation.
	"rlib",
]

Unfortunately in ink! we use rlib for generating ink! metadata.
For automating this process we have to somehow get rid of this rlib field during compilation in order to NOT to override the following profile section in Cargo.toml:

[profile.release]
panic = "abort"
lto = true
opt-level = "z"
codegen-units = 1

All these settings are very important to get all the important optimizations in the final Wasm binary.

After taking all these steps building a highly optimized ink! Wasm smart contract is just:

xargo build --no-default-features --target wasm32-unknown-unknown --release

So simply exchange cargo with xargo.
Also this still requires a pass by wasm-opt afterwards so this pass should be run before applying wasm-opt for final optimizations.

When compiling current cargo-contract master I receive the following warnings:

   Compiling cargo-contract v0.7.0 (/home/robrob/.cargo/git/checkouts/cargo-contract-0e593efc9d3a70d5/169c65b)
warning: use of deprecated associated function `zip::ZipWriter::<W>::start_file_from_path`: by stripping `..`s from the path, the meaning of paths can change. Use `start_file` instead.
  --> build.rs:96:17
   |
96 |             zip.start_file_from_path(name.as_path(), options)?;
   |                 ^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(deprecated)]` on by default

warning: use of deprecated associated function `zip::ZipWriter::<W>::add_directory_from_path`: by stripping `..`s from the path, the meaning of paths can change. Use `add_directory` instead.
   --> build.rs:103:17
    |
103 |             zip.add_directory_from_path(name.as_path(), options)?;
    |                 ^^^^^^^^^^^^^^^^^^^^^^^

warning: 2 warnings emitted

As well as the following errors when compiling contract-metadata:

   Compiling contract-metadata v0.1.0 (/home/robrob/.cargo/git/checkouts/cargo-contract-0e593efc9d3a70d5/169c65b/metadata)
warning: use of deprecated associated function `zip::read::ZipFile::<'a>::sanitized_name`: by stripping `..`s from the path, the meaning of paths can change.
                You must use a sanitization strategy that's appropriate for your input
  --> src/cmd/new.rs:60:41
   |
60 |         let outpath = out_dir.join(file.sanitized_name());
   |                                         ^^^^^^^^^^^^^^
   |
   = note: `#[warn(deprecated)]` on by default

warning: use of deprecated associated function `zip::read::ZipFile::<'a>::sanitized_name`: by stripping `..`s from the path, the meaning of paths can change.
                You must use a sanitization strategy that's appropriate for your input
  --> src/cmd/new.rs:78:34
   |
78 | ...                   file.sanitized_name().display()
   |                            ^^^^^^^^^^^^^^

warning: 2 warnings emitted

Currently cargo-contract builds under target which can interfere with other tools that do the same. The established common rule for tools like cargo-contract is to put every artifact under target/<name> and we should do this, too.

Currently not working because of paritytech/subxt#35

Do you have a plan to implement renaming the project name?

when I create the ink!'s project with

cargo contract new xxx

lib.rs would be like this

/* snip */
#[ink::contract(version = "0.1.0")]
mod xxx {
    /* snip */
    struct Xxx {
        /* snip */
    }
    impl Xxx {
        /* snip */
    }
    /*snip/
}

but, error occurs when I rename the struct name to Yyy, and run cargo contract generate-metadata.
In order to fix this, I manually have to edit .ink/abi-gen/main.rs

/* snip */
#[ink::contract(version = "0.1.0")]
mod xxx {
    /* snip */
    struct Yyy {
        /* snip */
    }
    impl Yyy {
        /* snip */
    }
    /*snip/
}

error[E0412]: cannot find type `Xxx` in crate `contract`
 --> .ink/abi_gen/main.rs:2:26
  |
2 |     let abi = <contract::Xxx as ink_lang::GenerateAbi>::generate_abi();
  |                          ^^^ not found in `contract`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0412`.
error: could not compile `abi-gen`.

Check if there is a newer version available on github and display to user

Contract metadata describes the storage in the layout section. A storage command should be introduced which utilizes this to allow inspection of a contract's storage from the command line.

So for the flipper:

#[ink::contract]
pub mod flipper {
    #[ink(storage)]
    pub struct Flipper {
        value: bool,
    }
}

Calling cargo contract storage --contract <contract_account> would result in the following:

Flipper { value: false }

This would work by using the metadata to generate keys and query the get_storage rpc: https://github.com/paritytech/substrate/blob/30ecb9b259140a860b20c662fda01b5b2c33e5fa/frame/contracts/rpc/runtime-api/src/lib.rs#L54.

The metadata would then be used to decode the results into human readable form, building on the "SCON" work done in #79.

For an initial implementation I think we don't need to do everything in a single PR, we can define a basic implementation that is useful and then add features as follow up PRs.

Lazy and Collections

We would need to consider how to handle the built-in lazy and collection types, they would probably require some custom display code.

Keys

It might be useful to be able to augment the data with the actual storage keys, and also query individual storage keys either by the raw key or by name.

Raw Storage

For debugging of corrupt storage it would be useful to be able to inspect the raw contract storage (without decoding).

cargo contract build ignores flags passed in through the RUSTFLAGS environment variable. Variables passed in through the cargo config are also ignored. The reason is likely that they are overridden here:
https://github.com/paritytech/cargo-contract/blob/f8f048fbace9c10bb414fb4da0df91df772a12d8/src/cmd/build.rs#L57-L61

They should be merged with the pre-existing options where pre-existing options take precedence in case of conflicts.

Likely a similar change is necessary for metadata generation.

Rel use-ink/ink#299

Cargo metadata should be used to extract the following and pass it to the ink_abi:

e.g.

• contract version
• ink! version
• rust version,
• author,
• license, etc.

If we are able to generate the main.rs (PR incoming) of the .ink/abi_gen then we can set those values directly e.g.

ink_abi::Metadata::build()
    .layout(contract_layout) // generated by ink!
    .general(contract_info) // generated by ink!
    .meta(cargo_toml_info) // injected by cargo-contract
    .finalize()

@Robbepop has discovered a regression in the wasm file size between 0.6.2 and 0.7.0. For the flipper ink! example:

• cargo-contract version 0.6.2 results in Wasm file size of 1.6kB
• cargo-contract version 0.7.0 (master) results in Wasm file size of 2.1kB.

We should also investigate the possibility of adding a CI check to catch these type of regressions.

With the upcoming merge of use-ink/ink#312 the ink! template is going to be in need of some adjustments.

• test-env is no longer forwarded to ink_core
• ink_primitives needs to be added (with std crate feature forwards)
• use ink_core::storage should be put inside the contract module
• #![feature(proc_macro_hygiene)] is no longer necessary
• ink_lang2 renamed to ink_lang

WIP (see todos)

Following on from the deploy command: use-ink/ink#134, the next step is to instantiate the contract on chain.

Command Name

The name of the command is important - we need to choose whether we should be consistent with the naming in polkadot-js UI:

• put_code => Upload
• create => Deploy.

For this we would need to change our existing deploy command to upload.

Alternatively we could align with the names of the contract runtime calls: put_code (or simply put?) and create.

UX

cargo contract create ARGS

Args

• code hash: the hash of the contract code on chain: result of the deploy command
• Endowment todo
• Gas: (optional) Max gas for deploying contract, defaults to 500000
• Url: (optional) Websockets url to a node on the target chain. defaults to http://localhost:9944
• Secret URI: The secret URI
• Counstructor Args todo

Output

Should return the AccountId of the instantiated contract.

Implementation

• See existing deploy implementation for constructing extrinsic utilising subxt

Constructor Args

• Need to figure out the best way to supply constructor args to be added to the extrinsic.
• Could support parsing of certain contract primitives from the command, and use contract abi metadata to determine the required signature and perform validation/parsing of the input. todo: elaborate

The cargo-contract plugin (ink! CLI) currently lacks support for setting a manifest-path as CLI parameter to make it usable on contracts without requiring the caller to have their cwd in the contract's root directory. The manifest-path should work the same as the one supported by Cargo and should be provided for

• cargo contract build
• cargo contract generate-metadata
• cargo contract deploy

Haven't tested this on Windows yet. Needs trying out and any issues fixing.

Also worth exploring adding a CI task.

The proposed cargo contract pack is going to do the following:

• Builds the contract: cargo contract build
• Builds the metadata of the contract: cargo contract metadata
• After both steps with their respective outputs in the target/ink directory the cargo contract pack command additionally packs the generated contract.wasm into the source.wasm field of the metadata.json file and stores it as contract.pack.

As follow-up the Canvas UI (and eventually Polkadot JS Apps) should build in support for the .pack extension and might even be able to drop support for non packed contracts completely.

After the giant merge of use-ink/ink#312. I think someone forgot the replace ink_lang2 with ink_lang in .ink/abi_gen/main.rs that make generate-metadata failed.

https://github.com/paritytech/cargo-contract/blob/master/src/main.rs#L42

Only lang is implemented, model is deprecated and we don't plan to support contracts written in the core abstraction. /cc @Robbepop

I think manifest is generated wrong? Should be there a contract_transfer.wasm?

We currently are not using wasm-opt's --strip-debug --vacuum --dce options. They might be useful to us to reduce the resulting .wasm files. Experimentation needed.

Following on from #58, we should support generating of metadata for the non-root contract in a multi contract workspace.

For example, the delegator example hosts multiple contracts which are dependencies of the main contract.

Proposal

• All metadata files will be written to the target directory of the workspace root, with the file name the same as the contract module name e.g. delegator.json, incrementer.json etc.
• cargo contract generate-metadata in the root workspace dir generates just the metadata for the root contract (in this case the delegator
• Sub contracts: e.g cd adder && cargo contract generate-metadata generates just the metadata for that sub contract.
• Alternatively cargo contract generate-metadata -p adder from the root does the same, mirroring cargo functionality.
• cargo contract generate-metadata --all will generate metadata files for all contracts in the workspace, e.g. delegator.json, adder.json, subber.json

Implementation notes

• Need to auto remove the ink-as-dependency feature in the root workspace manifest for the sub contracts

Currently we dynamically read from the Cargo.toml e.g. in manifest.rs:

https://github.com/paritytech/cargo-contract/blob/master/src/workspace/manifest.rs#L372-L379

We should investigate introducing some types and use serde to deserialize into them for strongly typed access. There might be a library somewhere or we can take inspiration from https://github.com/dtolnay/trybuild/blob/master/src/manifest.rs.

At the moment ink! smart contracts have all their panic messages included in the data segment of the Wasm binary even though execution aborts upon panic and will never output any panic messages.

This is due to a "bug" between Rust and LLVM translation.
We can manually optimize this superflous data away with LLVM's opt tool.
The passes we need to enable from it are:

• -deadargelim: https://llvm.org/docs/Passes.html#deadargelim-dead-argument-elimination
• -globaldce: https://llvm.org/docs/Passes.html#globaldce-dead-global-elimination
  Note that opt works on LLVM IR, not on Rust nor WebAssembly. So this needs some adjustments to the cargo contract build process.

The opt tool usage should be enabled by default, however, if it does not exist on a user machine the build process should simply do what it currently does (not use opt) and print a warning to the user stating that the resulting Wasm binary might not be optimal for the given reason.

Currently a warning is displayed if wasm-opt is not installed. However some users are not reading the warning.

https://github.com/paritytech/cargo-contract/blob/d28a743b32a77d2ab3ddb463d101e1fe91344b15/src/cmd/build.rs#L201-L208

Since contract authors would definitely want their contracts optimized (storage rent!), we should fail the build if it is not installed. They won't be able to ignore that.

If for whatever reason they want to still compile without installing wasm-opt, we should provide an option e.g. --no-wasm-opt or --skip-wasm-optimizations

Alternative

Investigate using https://github.com/pepyakin/binaryen-rs as a dependency so as not to require manual installation of wasm-opt

As part of #29 I added some colours to the build command.

The other commands could also benefit from some prettifying.

The template for the new command is the main coupling to ink!. The first ink release is coming soon so we should explore how to make the template compatible with different versions/editions of ink!.

One option would be to move the template to the ink! repository and pull the files from the ink version.

Follow up to #57, as discussed here use-ink/ink#299 (comment).

Types for extended contract metadata can be shared with https://github.com/hyperledger-labs/solang by extracting the types to their own crate.

To start with, we could add the crate as a workspace package in the cargo-contract repo.

Once ink! 3.0 is released

cargo contract build can take quite a while to build things, but it's output is quite quiet:

 [1/3] Collecting crate metadata
 [2/3] Building cargo project
 [3/3] Post processing wasm file
	Your contract is ready.
You can find it here:
...

It would be great to have a -v/--verbose flag that prints more often.

https://github.com/paritytech/cargo-contract/blob/cfc389db2370be7661d5d2b17596ca7b71bca2bc/src/cmd/build.rs#L59-L62

Might be nice to be able to build contracts written in solidity, by invoking https://github.com/hyperledger-labs/solang.

e.g. cargo contract build flipper.sol would detect the sol extension and attempt to build using solang. If the solang binary is not installed the user could be prompted to install it via https://solang.readthedocs.io/en/latest/installing.html.

When I execute cargo +nightly Contract build, I got an error.

 `rust-src` component not found. Run `rustup component add rust-src`.

But I think I have rust-src installed, and the rustup component list | grep rust-src also shows that I have rust-src installed.

I tried to specify rust-src manually through export XARGO_RUST_SRC=/home/nzzt/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library, and I succeeded in the next step, but unfortunately another error occurred.

I checked the directory on my computer and found that it didn't match the actual directory.

Hello, I've had a similar problem like #70 and I think instruction on https://substrate.dev/substrate-contracts-workshop/#/0/setup are fairly broken now.

I think problem is that cargo install cargo-contract --vers 0.6.1 --force doesn't update to recent cargo-xbuild-0.6.0 and that's where it gets stuck. On 0.7.0 there are I think different problems.

After I've bumped cargo-xbuild to version 0.6.0. I'm doing it right?

❯ rustup show
Default host: x86_64-apple-darwin
rustup home:  /Users/wao/.rustup

installed toolchains
--------------------

stable-x86_64-apple-darwin (default)
nightly-2019-11-06-x86_64-apple-darwin
nightly-2020-07-11-x86_64-apple-darwin
nightly-x86_64-apple-darwin

installed targets for active toolchain
--------------------------------------

wasm32-unknown-unknown
x86_64-apple-darwin

active toolchain
----------------

stable-x86_64-apple-darwin (default)
rustc 1.45.2 (d3fb005a3 2020-07-31)

Running cargo outdated on the ink! codebase yields that mainly ink! CLI is using some outdated dependencies.

cargo-contract
================
Name              Project  Compat  Latest  Kind    Platform
----              -------  ------  ------  ----    --------
futures           0.1.29   ---     0.3.1   Normal  ---
idna              0.1.5    ---     0.2.0   Normal  ---
percent-encoding  1.0.1    ---     2.1.0   Normal  ---
url               1.7.2    ---     2.1.0   Normal  ---

We could update futures to 0.3.1 and by this introduce the new async and await stuff from stable Rust. We should generally just update the others if simple enough.

rel: paritytech/subxt#36