bug: Non-contiguous circuit input indices crash compiler

[researchzero-sec]

Bug Report

Cairo version: 6a3c423

Current behavior:

A core::circuit circuit whose CircuitInput<N> indices are not contiguous from 0 — either a gap (e.g. using CircuitInput<0> and CircuitInput<2>, skipping <1>) or a non-zero start (e.g. a lone CircuitInput<5>) — causes a compiler panic during Sierra type-specialization instead of producing a clean diagnostic:

thread 'main' panicked at crates/cairo-lang-sierra-generator/src/db.rs:370: Got failure while specializing type `Circuit<(...CircuitInput::<0>, ...CircuitInput::<2>...)>`: Could not specialize type

The Sierra Circuit type assumes its inputs form a contiguous 0..N set, and the non-contiguity is keyed on the input index set of the resulting Circuit<(<output>,)> type (what the output transitively depends on), not merely the syntactically-declared CircuitElements. So selecting a lone non-zero input as a circuit output (e.g. output (CircuitInput<1>,) while inputs <0>, <1> are declared) also crashes the compiler. Reusing the same index in multiple gates (e.g. circuit_add(a, a) with a = CircuitInput<0>) is fine — only the contiguity of the index set matters.

Expected behavior:

A clean compiler diagnostic stating that circuit input indices must form a contiguous 0..N range, rather than an internal compiler panic. A developer refactoring a circuit (deleting a now-unused middle input, or starting indices at 1) reasonably expects an error, not an ICE.

Steps to reproduce:

Compile/run a circuit whose CircuitInput<N> indices have a gap or do not start at 0:

1. CircuitInput<0> + CircuitInput<1> (contiguous) → compiles and runs (3+2 = 5 mod 7).
2. Swap CircuitInput<1> → CircuitInput<2> (gap at index 1) → ICE.
3. CircuitInput<5> + CircuitInput<6> (no 0..4) → same ICE.
4. circuit_add(a, b) with a=<0>, b=<1> but output (b,) = CircuitInput<1> alone → same ICE (output input set {1} is non-contiguous).

Verified with cairo-test --single-file at commit 6a3c423.

Related code:

let a = CircuitElement::<CircuitInput<0>> {};
let b = CircuitElement::<CircuitInput<2>> {};   // GAP at index 1 -> ICE "Could not specialize type Circuit<...>"
let s = circuit_add(a, b);  // ... .eval(modulus) -> compiler panic at sierra-generator/db.rs:370

Other information:

• The panic site is the generic type-specialization failure at crates/cairo-lang-sierra-generator/src/db.rs:362-371, where CoreType::specialize_by_id(...).unwrap_or_else(|err| panic!("Got failure while specializing type {long_id}: {err}")) is hit because the Circuit<...> long-id encodes non-contiguous CircuitInput indices that fail specialize_by_id.
• The circuit builder (CircuitInput<N> / CircuitElement / circuit_add) lives in corelib/src/circuit.cairo; the Sierra Circuit type encodes its inputs by index and the specializer assumes a contiguous 0..N input set.
• The core::circuit docs always show circuits using contiguous indices from 0 (CircuitInput<0>, <1>, <2>) without stating that contiguity is required or that violating it is a crash rather than a diagnostic.
• Suggested fix direction: emit a diagnostic when a circuit's transitive input index set is non-contiguous (has a gap or does not start at 0), instead of panicking in the Sierra generator.