Description

String interpolation ("Hello, ${x}") generates invalid C code when the interpolated variable has wildcard type (?). The codegen emits (long long)(x) regardless of the actual resolved type, causing a C compiler error when the wildcard binds to a non-integer type (e.g. string, float, bool, char, array, map).

Reproduction

do main() {
    something("Marshall")
}

do something(x ?) {
    println("Hello, ${x}")
}

Expected: Prints Hello, Marshall

Actual: C compilation fails:

/tmp/ez_ez_run_93078.c:44:89: error: operand of type 'EzString' where arithmetic or pointer type is required
    ez_builtin_println_str(ez_string_format(ez_default_arena, "Hello, %lld", (long long)(x)));

Root Cause

In codegen.c NODE_INTERPOLATED_STRING handler (~line 770-812), when the typetable returns TK_UNKNOWN for a wildcard-typed parameter, the fallback logic defaults to TK_INT:

if (tk == TK_UNKNOWN) {
    if (part->kind == NODE_FLOAT_VALUE) tk = TK_FLOAT;
    else if (part->kind == NODE_BOOL_VALUE) tk = TK_BOOL;
    else if (part->kind == NODE_STRING_VALUE) tk = TK_STRING;
    else tk = TK_INT; /* default integer kind */
}

This causes the default branch to emit (long long)(x) which is invalid for EzString and other non-integer types.

The infix handler (~line 1184) already has the correct pattern — resolving TK_UNKNOWN via cg->wildcard_binding when active — but the interpolation handler lacks this resolution.

Fix

When tk == TK_UNKNOWN and cg->wildcard_binding is active, resolve the type via type_from_name(cg->wildcard_binding) before selecting the format specifier and argument emission, matching the existing pattern in the infix handler.

Affected Types

Any non-int wildcard binding used in string interpolation: string, float, bool, char, uint, array, map, struct, enum.