ABI for low-level contracts

[itegulov]

There are some rough edges when generating ABI for a low-level contract. For example it is unclear that the following function returns a promise and not a ():

pub fn factorial(&self, n: u32) {
    if n <= 1 {
        env::value_return(&serde_json::to_vec(&1u32).unwrap());
        return;
    }
    let account_id = env::current_account_id();
    let prepaid_gas = env::prepaid_gas() - FACTORIAL_CALL_GAS;
    let promise0 = env::promise_create(
        account_id.clone(),
        "factorial",
        &serde_json::to_vec(&(n - 1,)).unwrap(),
        0,
        prepaid_gas - FACTORIAL_MULT_CALL_GAS,
    );
    let promise1 = env::promise_then(
        promise0,
        account_id,
        "factorial_mult",
        &serde_json::to_vec(&(n,)).unwrap(),
        0,
        FACTORIAL_MULT_CALL_GAS,
    );
    env::promise_return(promise1);
}

Same thing with resolving callbacks: they are not a part of the signature so they will not show up in ABI. Not sure how big of a deal this is, but can be a potential foot gun as an ABI for the code will be successfully generated, but won't have the correct type. We could add some custom attributes (e.g. #[near_abi_returns(<type>)]) and/or warn user who is using cargo-near on a contract that contains env::promise_result(i) (and other similar calls).

[miraclx]

contract that contains env::promise_result(i)

Hm, that's tricky, what if the return is inside another function that's called from this one. Shouldn't happen, but there's nothing stopping it from happening.

[itegulov]

Yeah, it's going to be impossible to traverse the entire call tree outside of rustc, so I don't think we can do much here tbh.

[austinabell]

I wonder if the direction described in near/abi#1 could be useful