[DanielLuning]

What changed

priv/defk_runtime.h now says which of its names the generated C uses. Before, the interface could only be learned from the emit strings in compiler.ex.

• The header: one comment block beside the "Responsibilities" index holds two marked lists.
  • interface:start/interface:end: the runtime names the generated C uses, in groups. A family uses the header's own notation (defk_get_<T>, DEFK_NF_<op>). Every other name in the header is internal.
  • kernel:start/kernel:end: the names the generated C defines itself (DEFK_SP, DEFK_SAVE<n>, defk_rs, the labels defk_l<n>, defk_lit_<hash>, ...).
• The test: test/runtime_interface_test.exs reads the names from the string literals of compiler.ex, raise.ex and strip.ex through the parsed code. It skips atoms, sigils and comments, and each #{...} in a name becomes a wildcard (defk_get_#{e} gives defk_get_*). Its three tests check that:
  • every name the compiler writes is in a list.
  • every listed name is one the compiler writes.
  • every interface name is defined in the header (a pasted defk_get_##T counts), and no name in the kernel list is a header name.
• The compiler map: the line count is now about 2,500 (it said about 1,900), and the section describes the lists.

Differences from the settled shape:

• More sources: raise.ex (the DEFK_E_* kinds) and strip.ex (a strip's rewritten C) also write runtime names, so the test reads them as well as compiler.ex.
• Strings, not raw text: a plain grep also picks up atoms, environment variables and regex sources.
• A weaker check for dynamic names: some names have no fixed part, such as defk_#{f}_#{s}, which gives defk_clz_i. Such an entry passes when each of its pieces is an atom or a string piece of the sources (:clz, "i"; lib/defk/builtins.ex is read for the word lists). This direction is weaker for those names, and the test comment says so. The wildcard approach was the owner's choice over writing the names out in the compiler.

Results

• No C change apart from the header's comment. The comment changes DEFK_HEADER_HASH, so every kernel's C changes in that one line. The scoreboard stamps hash the whole C, so mix defk.examples --stale now lists every stored row although no kernel code changed. Earlier header changes had the same effect.
• Checked with a mutation: with defk_mulhi replaced in the list by a made-up defk_bogus_x, all three tests failed, each with a message that names the problem. The list was then restored.

How it was checked

• mix ci on the laptop (macOS) passed: 2300 tests, Credo found no issues, Dialyzer reported 0 errors.

• The mutation run above.

• Touches a promised surface? No: the header changes only in a comment. No CHANGELOG.md entry.

• Touches test/stability/? No.