cargo contract throws error about supplied arguments in ` #[ink(constructor)]` for version 3.0.1

Question

In my smart contract, all the ink dependencies are set to =3.0.1 because of this issue: Cargo contract 3.0.1

When I tried to execute the cargo contract build or even cargo +nightly contract build to the flipper project, it results into this error:

error[E0061]: this function takes 2 arguments but 1 argument was supplied
  --> lib.rs:18:9
   |
18 | /         /// Constructor that initializes the `bool` value to the given `init_value`.
19 | |         #[ink(constructor)]
20 | |         pub fn new(init_value: bool) -> Self {
21 | |             Self { value: init_value }
22 | |         }
   | |         ^
   | |         |
   | |_________supplied 1 argument
   |           expected 2 arguments
   |
note: function defined here
  --> /home/.cargo/registry/src/github.com-1ecc6299db9ec823/ink_lang-3.0.1/src/codegen/dispatch/execution.rs:81:8
   |
81 | pub fn execute_constructor<Contract, F, R>(
   |        ^^^^^^^^^^^^^^^^^^^

error[E0061]: this function takes 2 arguments but 1 argument was supplied
  --> lib.rs:24:9
   |
24 | /         /// Constructor that initializes the `bool` value to `false`.
25 | |         ///
26 | |         /// Constructors can delegate to other constructors.
27 | |         #[ink(constructor)]
28 | |         pub fn default() -> Self {
29 | |             Self::new(Default::default())
30 | |         }
   | |         ^
   | |         |
   | |_________supplied 1 argument
   |           expected 2 arguments
   |
note: function defined here
  --> /home/.cargo/registry/src/github.com-1ecc6299db9ec823/ink_lang-3.0.1/src/codegen/dispatch/execution.rs:81:8
   |
81 | pub fn execute_constructor<Contract, F, R>(
   |        ^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0061`.
error: could not compile `flipper` due to 2 previous errors
Error: Compilation failed with toolchain `nightly-2022-03-14-x86_64-unknown-linux-gnu`

Caused by:
    command failed: "cargo" "check" "--target-dir" "/home/projects/flipper/target/dylint/target/nightly-2022-03-14-x86_64-unknown-linux-gnu" "--manifest-path" "/home/projects/flipper/Cargo.toml"
ERROR: `"/home/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo" "dylint" "--lib" "ink_linting" "--manifest-path=/home/projects/flipper/Cargo.toml"` failed with exit code: Some(1)

I'm at my wit's end. (I would like to specify that the substrate runtime is for polkadot-v0.9.18)

---

To replicate:

• I am using rustc 1.63.0-nightly (4cbaac699 2022-05-25)
• The cargo contract version is 1.4.
• The smart contract is the flipper:cargo contract new flipper
• And then in the .toml file:

[package]
name = "flipper"
version = "0.1.0"
authors = ["[your_name] <[your_email]>"]
edition = "2021"

[dependencies]
ink_primitives = { version = "=3.0.1", default-features = false }
ink_metadata = { version = "=3.0.1", default-features = false, features = ["derive"], optional = true }
ink_env = { version = "=3.0.1", default-features = false }
ink_storage = { version = "=3.0.1", default-features = false }
ink_lang = { version = "=3.0.1", default-features = false }

scale = { package = "parity-scale-codec", version = "3", default-features = false, features = ["derive"] }
scale-info = { version = "2", default-features = false, features = ["derive"], optional = true }

[lib]
name = "flipper"
path = "lib.rs"
crate-type = [
    # Used for normal contract Wasm blobs.
    "cdylib",
]

[features]
default = ["std"]
std = [
    "ink_metadata/std",
    "ink_env/std",
    "ink_storage/std",
    "ink_primitives/std",
    "scale/std",
    "scale-info/std",
]
ink-as-dependency = []

Answer 1

I had the same situation above. After specify indirect dependencies' version declaratively, I succeded to compile and deploy contracts to the local node with pallet-contracts polkadot-v0.9.19 support.

Please try to add below to Cargo.toml dependencies section.

ink_lang_codegen = { version = "=3.0.0", default-features = false }

I don't know exactly why and what was the breaking change. I'd like to know if someone knows it in detail. and other potential workarounds.

Answer 2

I've reproduced your issue and I believe it was an error on our end which caused this. It looks like we introduced a breaking change in the codegen as part of ink! 3.2, sorry!

This change was related to the execute_constructor method of the ink_lang crate. In #1264 we removed one of the arguments, which is what's causing this error.

Now, to break it down a little more. Let's consider the error you're getting:

error[E0061]: this function takes 2 arguments but 1 argument was supplied

The dependency graph looks something like this (taken from the Cargo.lock):

• name = "ink_lang", version = "3.0.1"
• name = "ink_lang_codegen", version = "3.2.0"

The [email protected] crate gets pulled in transitively by the [email protected] crate (you can use cargo tree to more easily spot this) because according to SemVer 3.2.0 is compatible with 3.0.1.

The [email protected] crate generates code as follows:

quote_spanned!(constructor_span=>
    Self::#constructor_ident(input) => {
        if #any_constructor_accept_payment && #deny_payment {
            ::ink_lang::codegen::deny_payment::<
                <#storage_ident as ::ink_lang::reflect::ContractEnv>::Env>()?;
        }

        ::ink_lang::codegen::execute_constructor::<#storage_ident, _, _>(
            move || { #constructor_callable(input) }
        )
    }
)

However, [email protected] (and also anything <3.2) exposes the following function:

pub fn execute_constructor<Contract, F, R>(
    config: ExecuteConstructorConfig,
    f: F,
) -> Result<(), DispatchError>;

When the Rust compiler tries to build the expanded macro code it fails because the function from ink_lang doesn't match the generated code, resulting in the error you are seeing!

By locking in the codegen at 3.0.1 you end up compiling code which is using the correct function signature.

quote_spanned!(constructor_span=>
    Self::#constructor_ident(input) => {
        ::ink_lang::codegen::execute_constructor::<#storage_ident, _, _>(
            ::ink_lang::codegen::ExecuteConstructorConfig {
                payable: #accepts_payment,
            },
            move || { #constructor_callable(input) }
        )
    }
)

Answer 3

Thanks for the issue reporting! Its origin is described in detail in @HCastano's answer, and is now fixed in the upcoming ink! 3.3.0 release along with other backwards compatibility breaking issues. Once the release is published, your ink! contracts (no matter on what 3.x.x version they depend upon) should being built smoothly again (no version overrides in Cargo.toml required). Stay tuned and have fun!