Support unbounded struct fields and nested sequence elements (follow-up to #4856 and #5240)

[AlbertoCentonze]

Version information

• Vyper: 0.5.0b2+commit.5764199a, master at 5764199a9ab64e13bc64d8f41371378db4fa6ab0 (checked September 5, 2026).
• Also observed at the port's pinned compiler, 8af5e83c10af4f065cc660fe20293dac11fdff83. The intervening commit changes only .github/workflows/codeql.yml.
• Python 3.13.14; macOS 26.6.2, arm64.
• Venom (--experimental-codegen), Cancun; bytecode metadata disabled.

Summary and relation to existing work

This is a focused follow-up to #4856 for recursive runtime-sized types, motivated by full input/output-domain compatibility in the Aave V4 Vyper port.

The open PR #5240 already addresses ABI-dynamic bounded elements in an unbounded outer array and explicitly references the Aave port. It also explicitly leaves DynArray[Bytes[INF], INF] rejected. This request concerns that remaining inner unbounded case and structs containing unbounded fields, rather than duplicating its bounded-element work.

Current limitations

These two separate minimal sources are rejected on the master commit above.

Unbounded bytes elements inside an unbounded array:

# pragma version 0.5.0b2
@external
@pure
def echo(values: DynArray[Bytes[INF], INF]) -> DynArray[Bytes[INF], INF]:
    return values

vyper.exceptions.StructureException: DynArray element types cannot contain unbounded sequence types

An unbounded array field inside a struct:

# pragma version 0.5.0b2
struct Batch:
    owner: address
    values: DynArray[uint256, INF]
@external
@pure
def count(batch: Batch) -> uint256:
    return len(batch.values)

vyper.exceptions.StructureException: Structs cannot contain unbounded sequence types

Compile each file separately with:

vyper --evm-version cancun --experimental-codegen -O 2 -f bytecode example.vy

Array probe, struct probe, pinned diagnostics. Both rejections were rechecked on current master.

Motivation

A bounded Bytes[N] element can have the same external bytes[] ABI encoding as Solidity while accepting only elements up to N bytes. An unbounded outer count alone therefore does not provide the full domain of a Solidity multicall.

Likewise, signed batch requests and configuration structs contain dynamic arrays. Imposing a fixed count inside those fields changes which otherwise valid ABI values can be accepted. This is language capability feedback, not a request to hide those restrictions behind larger constants or custom raw ABI decoders.

Requested scope

• Allow unbounded sequence fields inside non-storage structs and unbounded elements inside sequences, including combinations of the two.
• Support the corresponding runtime ABI decoding and encoding for parameters and return values, with allocation based on actual runtime sizes.
• Carry the supported types through internal calls, interface declarations, and exported module interfaces.
• Preserve existing bounded-type behavior; cover empty and nonempty nested values and exact round trips.

This request is about calldata/memory/return values. Runtime-sized persistent storage is a separate design topic. Capturing complete successful external-call returndata is also a separate prerequisite for a fully generic multicall.

[harkal]

• Unbounded elements inside unbounded sequences (DynArray[Bytes[INF], INF]): this is the planned follow-up to feat[venom]: allow abi-dynamic elements in inf dynarrays #5240. feat[venom]: allow abi-dynamic elements in inf dynarrays #5240 deliberately stops at ABI-dynamic bounded elements because those keep a contiguous, statically strided payload. Unbounded elements need per-element indirection (each element owns its own runtime-sized allocation), which touches element assignment, copies, append, ABI encode/decode and the memory alias passes. Scoped, not started; it will be its own PR after feat[venom]: allow abi-dynamic elements in inf dynarrays #5240 merges.
• Unbounded fields in non-storage structs: not planned yet. It shares most of the machinery above (an indirection cell inside an aggregate, deep copy, decode-time allocation) but with a static member count, so it may well be the cheaper of the two. Which of the two blocks the port harder? That would decide the order.
• raw_call(..., max_outsize=INF): tracked separately, agreed it is a prerequisite for a generic multicall. The max_outsize=INF spelling in your probe is the shape I'd go with.
• Storage: agreed, separate topic.

[charles-cooper]

alternative to max_outsize=INF is eliding it (paging @Sporarum )

[AlbertoCentonze]

IMO max_outsize=INF and elision should be equivalent

[charles-cooper]

yes, but INF currently only exists at the type level, max_outsize=INF would need an awkward workaround

[Sporarum]

yes, but INF currently only exists at the type level, max_outsize=INF would need an awkward workaround

Of the top of my head, I feel like it wouldn't be that hard, INF is a constant, that just so happens to be invalid everywhere except some types, by relaxing this restriction, we should be able to implement it

[harkal]

I am in the process of implementing this, and now i guess we need to decide on max_outsize=INF... i suggest we keep it in the way @Sporarum says, and in the future we can always elide it as a separate language change. What do you think?

[harkal]

max_outsize=INF implementation: #5271

[AlbertoCentonze]

@harkal tested the PR on the aave port, looking good!

Great news! Thank you for testing this!

[harkal]

@AlbertoCentonze your struct example above should compile now under #5282

[AlbertoCentonze]

Thank you @harkal will test it on Monday and keep you posted