Wrong constant value in the signers.clar boot contract about clarity-wasm

[hugocaillard]

I think that it's same issue but with another use case, in the pox-4 contract we use an expression to define the STACKING_THRESHOLD constant, it evaluates to 0 in WASM

(define-constant STACKING_THRESHOLD_25 (if is-in-mainnet u20000 u8000))

(define-read-only (get-st25)
  STACKING_THRESHOLD_25
)

In because the contract also does

(define-read-only (get-stacking-minimum)
    (/ stx-liquid-supply STACKING_THRESHOLD_25))

it leads to a division by zero when we call get-stacking-minimum or get-pox-info (which the new boot contract signers-voting.clar does, so it can't be deployed in clar2wasm)

[Acaccia]

So, after a little bit of investigation, the bug is caused by the fact that a constant which is not a literal value is not evaluated if it's called from inside a function. This is because in this case, .top-level is not evaluated.

We have to make sure that an accessed constant has been evaluated first.

Here is a simple way to reproduce the bug in the clar2wasm-tests package:

1. Add the contract constant-expr.clar with this content:

(define-constant FOO (+ 1 1))

(define-public (get-constant)
	(ok FOO)
)

2. Add in lib_tests.rs this test:

test_contract_call_response!(
    test_contract_constant_expr,
    "constant-expr",
    "get-constant",
    |response: ResponseData| {
        assert!(response.committed);
        assert_eq!(*response.data, Value::some(Value::Int(2)).unwrap());
    }
);

[Acaccia]

Our traverse function for define-constant should also handle other cases than literal values at compile time, like atoms for reserved variables (e.g. tx-sender).