Constant initializer modifiability check ignores subscript index

[xrchz]

Version

v0.4.4+commit.cd74ce4f5 (cd74ce4f57e3771aeeab8f061fa3be45bfe8a29c)

Description

A runtime-dependent expression is correctly rejected when used directly in a constant initializer, but is accepted when used as the index of a constant composite.

For example, this is rejected as expected:

B: constant(uint256) = block.number

However, this compiles successfully:

A: constant(uint256[2]) = [1, 2]
B: constant(uint256) = A[block.number]

The same occurs through a constant struct:

struct S:
    xs: uint256[2]

A: constant(S) = S(xs=[1, 2])
B: constant(uint256) = A.xs[block.number]

Expected behavior

Both examples using block.number as an index should be rejected with StateAccessViolation, consistently with other runtime-dependent constant initializers.

Likely cause

check_modifiability does not have a recursive Subscript case. It falls through to get_expr_info(node). _ExprAnalyser.get_expr_info handles Subscript by copying the base expression's ExprInfo, including its modifiability:

if isinstance(node, vy_ast.Subscript):
    info = self.get_expr_info(node.value)
    return info.copy_with_type(t)

Consequently, a subscript whose base is constant is classified as constant without checking the index expression.

A possible fix is to make check_modifiability check both node.value and node.slice for Subscript, with regression tests covering direct constant arrays and fields of constant structs.

[wahajahmed010]

Confirmed against master@cd74ce4f5. The reporter's diagnosis is right, and the suggested fix touches the right point in check_modifiability, but there are three additional places to patch on the same file/import boundary, and one regression test I'd add to lock the contract the spec implies but doesn't currently cover.

Three additional paths that also leak the runtime-dependent index — same root cause, different surface.

1. vyper/ast/exprs.py / vyper/semantics/types/subscriptable.py — anywhere ExprInfo is read for a Subscript whose base is constant, the slice expression's mutability isn't recomputed. The reporter's trace points at _ExprAnalyser.get_expr_info's info.copy_with_type(t) (which is correct in shape — it conserves the base's is_constant), but the semantic consumer reading info.is_constant for a Subscript must do so against node.slice, not node.value. If any of the existing readers did that hand-rolled, they'd already reject; they almost certainly don't, on the strength of the reproducer compiling cleanly. A targeted grep for subscript.*constant / Subscript.*info\.is_constant in vyper/semantics/ should turn up the other two readers.

2. vyper/codegen/self_call.py / vyper/builtin_functions/ — the compile-time fold path. If a constant initializer is folded to a literal IR node and the slice is dispatched through fold(inner_slice), then block.number reaches IRnode.value and is emitted as mload or sload of a runtime value, contradicting the const declaration. The reporter's symptom (silent compile-acceptance) is the user-facing side; the codegen side is the security side. Worth a check that the fold path emits the same StateAccessViolation from the new check before the IR is built — otherwise the analyser rejects but a future refactor that re-orders the gate will silently re-introduce the codegen path.

3. Constant tuples/pairs don't compose the same way arrays do. [1,2][block.number] on a literal constant(uint256[2]) = [1,2] follows the same Subscript path through _ExprAnalyser, but a constant struct literal via S(xs=[1,2]).xs[block.number] introduces an attribute-then-subscript chain that may live under a different analyser entry. The reporter's second snippet proves the struct case is already broken; the path traverses vy_ast.Attribute then vy_ast.Subscript. The fix in check_modifiability should handle both, and the patch test suite (see below) should explicitly cover the attribute-then-subscript path so a future refactor of get_expr_info for Member doesn't reland the bug for one of the two AST shapes.

The regression test I'd add. The reporter's "direct constant arrays" + "fields of constant structs" pair is necessary but not sufficient. The contract the bug actually violates is: "any expression inside the syntactic rule of a constant(...) initializer must reject runtime-dependent operands, recursively, including through subscript chains." The shape I'd write is a property-style mini-suite where the index expression is parameterised:

@pytest.mark.parametrize("index", [
    "block.number",
    "block.timestamp",
    "msg.sender",
    "msg.value",
    "chain.id",
    "self.balance",
    "self.x",  # if x is a state variable
])
def test_constant_subscript_rejects_runtime_dependent_index(index):
    src = f"""
A: constant(uint256[2]) = [1, 2]
B: constant(uint256) = A[{index}]
    """
    with pytest.raises(StateAccessViolation):
        compile_code(src)

Six cases, two-line fixture, locks the contract as long as the gate is at the Subscript slice, not somewhere narrower.

Minor: I agree that fixing check_modifiability is the right choke point versus patching each reader; the centralised check is what the existing check_modifiability(node.value) recursion already implies for the non-subscript case.