Infer int[N] and bool[N] literal types in debug_value_types - #167
Open
oskrcl wants to merge 2 commits into
Open
Conversation
The `ExprKind::Array` arm of `infer_debug_expr_value_type` only handled
`byte[N]` literals; `int[N]` and `bool[N]` array literals in
`validateOutputState` body expressions silently fell through to the
`dynamic_bytes()` fallback, which downcasts their inferred type to
`byte[]` and causes downstream VOS encoding to throw type-mismatch
errors against declared `int[N]`/`bool[N]` state fields.
This blocks covenant authors from writing `validateOutputState(0, { winners:
[0, 1, 2, 3] })` in a hand-shape-preserving way, requiring workarounds
such as per-element assignments or field-ref encoding.
Add parallel `else if` arms for `ExprKind::Int` (returns `int[N]`) and
`ExprKind::Bool` (returns `bool[N]`). Heterogeneous arrays still fall
through to `dynamic_bytes()` (byte[]), preserving prior behavior.
Test coverage:
- New unit test `infers_int_and_bool_array_literal_value_types` in
debug_value_types.rs tests module (4 assertions: int[4] + bool[2] +
mixed→byte[] regression + byte[2] regression guard).
- New integration test `vos_int_array_literal_infers_correct_type` in
compiler_tests.rs that compiles a covenant with `int[4] winners` state
field and a `validateOutputState(0, { winners: [0, 1, 2, 3] })` body,
verifying the inferred type matches the declared field.
Scope: +6 LOC in the Array arm + 1 unit test + 1 integration test. No
other file touched.
Target: upstream kaspanet/silverscript master (rebased off `2a3961c`).
Companion PR draft for v1.2 `silverscript-mod` divergence retirement.
…rays Oracle F1 (gate 1): the prior integration test compiled input and output with identical ctor args, so the test only proved the contract compiles, not that VOS encoding actually differs for different int[4] literals. Add a 2nd compile with swapped array values and assert the compiled bytecode differs — proving the fix encodes each value through VOS splice rather than falling back to identity-state passthrough.
oskrcl
force-pushed
the
fix/int-n-bool-literal-inference
branch
from
July 25, 2026 18:04
3ccb2a0 to
94e13a5
Compare
Author
|
Force-pushed to replace merge-based history with a clean 2-commit revision. New head:
Replaces old head: The spike fixture is dropped: it is not referenced by tests, and the regression test now proves the fix more directly by compiling the same source with different No functional change intended relative to the compiler fix; history is now linear and based on |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
infer_debug_expr_value_typeonly recognizesbyte[N]array literals.int[N]andbool[N]literals fall through to the catch-all"byte[]"type, which causes
validateOutputStateto reject state fields writtenwith array literals. A field passed by reference (
{ winners: winners })compiles fine because the declared type from the
typesmap bypassesliteral inference; a field passed by literal (
{ winners: [1,2,3,4] })fails until this fix lands.
Changes
silverscript-lang/src/compiler/debug_value_types.rs— in theExprKind::Arrayarm ofinfer_debug_expr_value_type, inferint[N]for all-
Intliterals andbool[N]for all-Boolliterals, alongsidethe existing
byte[N]case. Empty literals now infer"byte[]"explicitly (previously
"byte[0]"via vacuous.all()on an emptyiterator).
silverscript-lang/tests/compiler_tests.rs— new testcompiles_validate_output_state_with_int_array_literalexercisesvalidateOutputState(0, { x: x + 1, winners: [1,2,3,4] }).silverscript-lang/tests/examples/b3c_array_spike.sil— showcasefixture mirroring the inline test.
silverscript-lang/src/compiler/debug_value_types.rs#[cfg(test)]unit test
infers_fixed_array_literal_value_typespins all three newinference branches (
int[N],bool[N], empty).Test Evidence
cargo test -p silverscript-lang— 305 passed, 0 failed.[1,2,3,4]infers as"byte[]",compile_encoded_state_objectrejects unsized field typewith
validateOutputState does not support field type byte[].b3c_array_spike.sil(literal) compiles only after the patch.declared type); verified empirically.
Notes
bool[N]ctor-binding from Rust (Expr::From<Vec<bool>>) is aseparate bug filed in the upstream issue tracker; not addressed here.
state {}declarations blockpatched.