Summary
Using a named constant as an array size panics the compiler with a todo! instead of producing a diagnostic (or resolving the constant).
Reproduction
const N: i32 = 3;
fn main() -> i32 {
let arr: [i32; N] = [1, 2, 3];
let i: i32 = 0;
return arr[i];
}
$ infs build const_array_size.inf
Parsed: const_array_size.inf
thread 'main' panicked at core/type-checker/src/type_info.rs:489:9:
not yet implemented: Constant identifiers for array sizes not yet implemented: N
Reproduced on main (type_info.rs last touched by #226).
Root cause
extract_array_size_from_arena (core/type-checker/src/type_info.rs) handles only Expr::NumberLiteral and explicitly todo!s on Expr::Identifier:
fn extract_array_size_from_arena(arena: &AstArena, size_expr_id: ExprId) -> u32 {
let expr_data = &arena[size_expr_id];
if let Expr::NumberLiteral { value } = &expr_data.kind {
return value.parse::<u32>().unwrap_or(0);
}
if let Expr::Identifier(ident_id) = &expr_data.kind {
todo!(
"Constant identifiers for array sizes not yet implemented: {}",
arena[*ident_id].name
);
}
0
}
Notes on the surrounding behavior:
- The parser rejects arithmetic expressions in array-size position (
[i32; 2 + 1] is a parse error), so the identifier arm is the only reachable non-literal case; the trailing 0 fallback is effectively defensive.
- The
NumberLiteral arm's value.parse::<u32>().unwrap_or(0) silently turns an out-of-range literal (e.g. [i32; 5000000000]) into a zero-sized array rather than reporting a diagnostic — worth fixing in the same pass.
Expected
Either resolve the constant at compile time (the general mechanism is #79, with CTFE restrictions tracked in #190) or emit a proper type-checker diagnostic ("array size must be an integer literal" / "constant array sizes are not yet supported") instead of crashing. A compiler should never todo!-panic on accepted syntax.
Context
Found while writing hit-test/AST-walk coverage tests for the LSP work (PR #239): test fixtures with a named-constant array size panic the analysis instead of yielding diagnostics, which also means the LSP server would crash-loop on such a file.
Related: #79 (comp-time constant resolution), #190 (CTFE-restriction enforcement).
Summary
Using a named constant as an array size panics the compiler with a
todo!instead of producing a diagnostic (or resolving the constant).Reproduction
Reproduced on
main(type_info.rslast touched by #226).Root cause
extract_array_size_from_arena(core/type-checker/src/type_info.rs) handles onlyExpr::NumberLiteraland explicitlytodo!s onExpr::Identifier:Notes on the surrounding behavior:
[i32; 2 + 1]is a parse error), so the identifier arm is the only reachable non-literal case; the trailing0fallback is effectively defensive.NumberLiteralarm'svalue.parse::<u32>().unwrap_or(0)silently turns an out-of-range literal (e.g.[i32; 5000000000]) into a zero-sized array rather than reporting a diagnostic — worth fixing in the same pass.Expected
Either resolve the constant at compile time (the general mechanism is #79, with CTFE restrictions tracked in #190) or emit a proper type-checker diagnostic ("array size must be an integer literal" / "constant array sizes are not yet supported") instead of crashing. A compiler should never
todo!-panic on accepted syntax.Context
Found while writing hit-test/AST-walk coverage tests for the LSP work (PR #239): test fixtures with a named-constant array size panic the analysis instead of yielding diagnostics, which also means the LSP server would crash-loop on such a file.
Related: #79 (comp-time constant resolution), #190 (CTFE-restriction enforcement).