Constructing imported composite record values can fail with unrelated internal type errors

[ehartford]

Current behavior

Constructing a user-facing record that contains imported record types can fail with an unrelated internal type error.

Example shape:

use demo.ir
use demo.program

pub error E = Bad

fn make_source(entry: str) -> Result[ProgramSource, E]:
    Ok(ProgramSource {
        ir: empty_ir(),
        ir_text: "",
        entry,
        spec_constants: Vec.new(),
    })

fn main:
    assert(true)

with run reports an error about some unrelated internal struct field rather than pointing at the ProgramSource { ... } construction site.

Generic repro

mkdir -p /tmp/wbug/lib/demo

cat > /tmp/wbug/lib/demo/ir.w << 'EOF2'
pub type IRProgram = {
    insts: Vec[i32],
    num_params: i32,
}

pub fn empty_ir -> IRProgram:
    IRProgram { insts: Vec.new(), num_params: 0 }
EOF2

cat > /tmp/wbug/lib/demo/program.w << 'EOF2'
use demo.ir

pub type ConstantDesc = {
    name: str,
}

pub type ProgramSource = {
    ir: IRProgram,
    ir_text: str,
    entry: str,
    spec_constants: Vec[ConstantDesc],
}
EOF2

cat > /tmp/wbug/main.w << 'EOF2'
use demo.ir
use demo.program

pub error E = Bad

fn make_source(entry: str) -> Result[ProgramSource, E]:
    Ok(ProgramSource {
        ir: empty_ir(),
        ir_text: "",
        entry,
        spec_constants: Vec.new(),
    })

fn main:
    assert(true)
EOF2

cd /tmp/wbug && with run main.w

Expected behavior

The record construction should compile, or the compiler should report a direct and relevant error at the construction site.

It should not fail with a message about an unrelated internal runtime type.

Why this matters

This makes ordinary helper functions that return imported record types much harder to debug. Users end up chasing internal compiler/runtime names instead of the code they wrote.