013 submodule variant key matches

✓ Passing This code compiles and runs correctly.

Code

// Pins that a `build:variants` key for a SUBMODULE event actually selects.
//
// The key is written the way the program IMPORTS the module — `mylib/pump:run`
// — while the call site is canonicalized to the module's LOGICAL name,
// `mylib.pump:run`. An exact string compare never matched, so the registration
// parsed, `configured` fired, and every call site quietly kept the default
// handler. Selecting a variant on a submodule could not work at all.
//
// It hid because a TOP-LEVEL event has no separator to disagree about
// (`"input:pump"` is spelled identically on both sides), and every variant test
// in the suite used one. Orisha's own `[build(linux)]` line, selecting its
// epoll pump, had never taken effect either.

import std/io
import std/build
import mylib/pump

std/build:variants {
    "mylib/pump:run": "alt"
}
| configured _ |> _
| skipped _ |> _
| invalid-event _ |> _

mylib/pump:run(n: 1): r |> std/io:print.ln(r)

input.k

Actual

alt

Expected output

alt

Flows

flow ~variants click a branch to expand · @labels scroll to their anchor

variants (source: "mylib/pump:run": "alt")

flow ~run click a branch to expand · @labels scroll to their anchor

run (n: 1)

Imported Files

// The package index exists so `mylib` resolves as a directory.
~pub tor unused-marker { } -> i32
~unused-marker -> 0

lib/index.kz

// A SUBMODULE event with two proc variants. The variant is selected by a key
// the author spells the way the import reads — `mylib/pump:run`.

const std = @import("std");

~pub tor run { n: i32 } -> string

~proc run|zig {
    _ = &n;
    return "default";
}

~proc run|alt {
    _ = &n;
    return "alt";
}

lib/pump.kz

Test Configuration

MUST_RUN

← 012 registered variant beats the inline splice 014 submodule variant effect arm at a subflow head →