Compiler panic in codegen: `internal error: entered unreachable code` on empty-tuple destructure of a void builtin call

[jubnzv]

The compiler panics with internal error: entered unreachable code in src/codegen/expression.rs:3813 (emit_function_call's catch-all arm) when an empty tuple destructure () = builtin(...) is lowered with a void-returning builtin (e.g. print) on the RHS.

MRE:

contract C {
    function f() public {
        () = print("x");
    }
}

Reproduce: save as mre.sol, run solang compile --target polkadot mre.sol.

Output:

thread 'main' panicked at src/codegen/expression.rs:3813:14:
internal error: entered unreachable code
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behavior: sema rejects the empty-tuple destructure (no values to assign) with a proper diagnostic, instead of letting the malformed assignment reach codegen.

Reproduces on solana, polkadot, evm. The same panic does NOT trigger when the RHS is a user-defined void function (() = g() is rejected cleanly), only when the RHS is a void builtin like print.

Git commit: 901bfb9
Build: release
rustc 1.96.0-nightly (562dee482 2026-03-21)

[aryanbaranwal001]

Hi, I have been looking into this panic and traced it to the root cause.

Root cause

destructure_values (src/sema/statements.rs:1772) validates the RHS of a destructure assignment (line 1906, 1910) by comparing return counts. But builtins like print slip through.

print is declared in the builtin table at src/sema/builtin.rs:63 with ret: vec![Type::Void]. When print("x") appears as the RHS of a destructure, the flow is:

1. destructure_values hits the pt::Expression::FunctionCall branch (statements.rs:1783) and calls function_call_expr (function_call.rs:2427).
2. Inside function_call_expr, at line 2455, builtin::is_builtin_call is true and builtin::resolve_call is called (line 2457), which finds the matching Prototype, through BUILTIN_FUNCTIONS in sema/builtin.rs constructing Expression::Builtin { tys: func.ret.to_vec(), kind: Print, .. } => func.ret is vec![Type::Void], so tys: [Type::Void].
3. then Expression::Builtin { kind:Print, tys: [Type::Void] } is returned as res back to destructure_values at line 1795.

Now in destructure_values, at line 1903:

let mut right_tys = expr.tys();   // =>  [Type::Void]

// line 1906 truncation:
if right_tys.len() == 1 && (right_tys[0] == Type::Unreachable || right_tys[0] == Type::Void) {
    right_tys.truncate(0);         // => []
}

// line 1910 count check:
if left_tys.len() != right_tys.len() {   // 0 != 0 => false => no error

The truncation at line 1906 converts [Type::Void] to [], making both sides zero. The count check passes, destructure_values returns Ok(expr) (line 1954), and Statement::Destructure(loc, [], print_expr) is stored in the AST (sema/statements.rs:1769).

where codegen panics

In codegen, Statement::Destructure is lowered by destructure() at src/codegen/statements/mod.rs:857.

At line 934 there is a catch-all arm that calls emit_function_call on anything that is not a List. emit_function_call (src/codegen/expression.rs:3372) only has arms for InternalFunctionCall, ExternalFunctionCall, and Builtin { kind: AbiDecode }. kind: Print matches none of them and hits _ => unreachable!() at line 3813 — panic.

The fix belongs in sema: reject the void expression before it reaches codegen.

Proposed fix

Option A

The fix belongs in destructure_values (sema/statements.rs:1772), right after function_call_expr returns in the pt::Expression::FunctionCall branch (line 1794). At that point res is already the fully resolved sema expression, so we can check its types before the truncation at line 1906 discards the type::void

// after function_call_expr returns res (line ~1794):
let tys = res.tys();
if tys.len() == 1 && (tys[0] == Type::Void || tys[0] == Type::Unreachable) {
    diagnostics.push(Diagnostic::error(
        *loc,
        "expression does not return a value".to_string(),
    ));
    return Err(());
}

This also blocks () = g() for user-defined void functions. That is because res (Expression), function_call_expr returns, both print("x") and g() carry identical tys: [Type::Void]

Hence both arrive at our fix as [Type::Void], and the check fires for both.

Extension to NamedFunctionCall: the same check should be added after named_function_call_expr returns in the pt::Expression::NamedFunctionCall branch (line ~1808). A user-defined function can be called with named args (g({a: 1})), and producing InternalFunctionCall { returns: [Type::Void] } identically. Without this extension, () = g({a: 1}) would slip through.

Option B

If () = g() should remain valid, we can narrow the check to only reject builtins that return Type::Void i.e. gate the check with matches!(res, Expression::Builtin { .. }) so user-defined void functions pass through untouched.

@salaheldinsoliman @seanyoung
Could you please guide as to which option I should be making a pr for?
Would greatly appreciate the input.