fix: a bare [[sysio::table]] phantom entry, and --use-rt never reaching the linker

[heifner]

Split out of #111. The first defects were found by porting a representative multi_index contract and building it, rather than reading the migration guide back; the rest came out of reviewing that fix.

The rule

A table row is a struct the contract declares, and its name is plain text. Everything else — a scalar, std::string, checksum256, a container, variant, binary_extension; a name with an escape, a splice, whitespace or punctuation — is refused with a diagnostic naming the row and the fix.

That is the rule upstream Antelope CDT has always enforced, so a contract ported from another Antelope chain behaves here as it did there. An earlier revision of this branch tried to describe those shapes instead and it was not worth it: a scalar row crashed the compiler, containers needed sugar reconstruction that mis-declared nested ones, variant aborted on a canonical argument pack. Narrowing to the rule removed 687 lines net.

docs/abi-tables.md is the reference: every supported declaration form, _n vs _i naming, [[sysio::kv_key]], and each diagnostic with its one-line fix. Legacy multi_index and singleton stay first-class — they are the transition path.

What was broken

1 — A bare [[sysio::table]] emitted a second table. The struct name stood in as a placeholder and was emitted alongside the entry the multi_index instantiation produced, so the stock Antelope idiom gave two ABI tables for one and get_table_rows on the struct's name described a table with no rows. No entry is emitted for a bare attribute now: the name, table_id and key layout all come from the instantiation, and a placeholder cannot be told from a real entry by anything that survives into the descriptor.

2 — No singleton had ever appeared in an ABI. sysio::singleton is an alias template over kv_singleton, and an alias template has no specialization of its own; the visitor tested for the name singleton and never matched. sysio::multi_index is the same shape over kv_multi_index, which was on the list — so a contract mixing the two saw its multi_index tables described and its singletons silently omitted. A Wire regression from the KV port, not a missing feature: upstream eosio::singleton is a real class template.

Two more surfaced once singletons reached that branch. A row that is not a class crashed the compiler (exit code 139); it is refused with a diagnostic now. And a table held as a data member admitted nothing — defined_in_contract() matched an alias and not a member — so a member over an unannotated row emitted no table while the contract built clean.

3 — [[sysio::table("name")]] was applied per translation unit, where neither condition it must respect is knowable. Two tables given one name collapsed to whichever the set reached first, and the survivor's type then described one table while its table_id addressed the other. The annotation is recorded in the descriptor now and resolved by cdt-codegen after the merge: applied when the row backs exactly one table and the name is free, refused with a warning otherwise. Resolution is a fixed point, so a rename that frees the name another wants no longer depends on which .desc merged first.

4 — --use-rt was accepted and then discarded. cdt-cpp parses the flag but only cdt-ld acts on it, and it was missing from the forwarding list — so a long double contract could not be built in one step, failing on librt's undefined f128_* symbols with a diagnostic telling the user to pass the flag they had just passed. One line. Only the negative case had a test, which is why the hint stayed correct while the flag did nothing.

5 — Three examples did not work. Postfix itr++ on a KV iterator; a row struct whose default member initializers fire kv_multi_index's static_assert while the compiler is still inside the enclosing class; and hash_id_example, which described no tables at all. Nothing builds examples/, so nothing caught them; all eight are compiled by hand here.

6 — A named table in a shared header refused to link (Error, ABI structs malformed : cfg already defined). Each TU decided on its partial view and the descriptors disagreed. Descriptors carry the row's qualified name and the annotation now, and both are stripped before the .abi is written.

7 — A table_id of zero read as no table_id. The hash is an unrestricted uint16_t and zero is one of its values, so a real id was dropped from the descriptor and both tables fell out of the collision check that exists to catch exactly that.

8 — Table names were never checked. A C++11 attribute's argument is taken from source text rather than the compiler's cooked value, so an escape stays uncooked and an odd spelling reaches the ABI. That reading is pre-existing and unchanged here; what is new is a charset: letters, digits, underscore and dot. It is the one constraint worth enforcing, since these names are read downstream by wire-sysio, SHiP and Hyperion — and it catches the escape case for free, a backslash not being in the set. How to write a name plainly is documented rather than enforced.

ABI changes

Fixture / example	Change
kv_key_types, singleton_contract	lose phantom entries from bare attributes
singleton_contract, examples/singleton_example, examples/hash_id_example	gain the tables they never described
test_contracts/kv_global_tests	2 entries → 9, one per kv::global declared
kv_key_types, named_table_attr	custom and declared lose a guessed table_id

Contracts using a singleton, or holding a table as a data member, gain entries. No entry a contract writes to is lost silently: two tables under one name still collapse, but that is reported with both table_ids, row types and key layouts.

Deliberate breaks. Two. A non-struct row is now an error — singleton<"cfg"_n, uint64_t> compiled before and described nothing, so anything relying on it already shipped an ABI that did not describe its state. And a table name must be letters, digits, underscore or dot (. being part of the _n alphabet), because these names leave the toolchain in the ABI and are read by wire-sysio, SHiP and Hyperion; all 88 distinct annotation names in wire-sysio, and all 52 here, already satisfy it.

Verification

• Toolchain 66/66 (from 44); ctest 34/34 with ENABLE_INTEGRATION_TESTS=ON.
• wire-sysio: 19 .wasm and 19 .abi byte-identical to a toolchain built at the review base, and to the artifacts committed there. Checkable rather than lucky: those contracts use no singleton, no _i, no [[sysio::kv_key]] and no container row, while their 89 uses of the named annotation do go through the new resolver.
• Every table_id in the new fixtures checked against an independent reimplementation of compute_table_id, _i hash path included.
• Eleven mutations, each failing only its own fixtures. Four tests passed against the code they were meant to catch before that: cdt-codegen sorts its descriptor list so --desc-file order is ignored; a shared header lets the per-TU annotation set drop a duplicate before the merge sees it; an abigen-fail fixture is satisfied by any non-zero exit, so a row that fails regardless masks one that stops failing; and a vector-of-vectors is refused with or without the guard meant to refuse it. Each is written into the fixture that hit it.

Not fixed here

examples/ still is not built by anything. .desc carries no version stamp, so an in-place toolchain upgrade can mix vintages — unit/abimerge_tests pins the one instance this PR would otherwise hit. A table declared only as a local variable over an unannotated row is not described, as upstream. A rename needing two names swapped at once is refused. Two C++ declarations sharing an unqualified name still collapse to one ABI type.

[huangminghuang]

[P1] Suppression fails across translation units

This check only sees tables generated during the current Clang invocation. If another source includes the bare-table row without instantiating the multi_index alias, its descriptor still contains the phantom table, and the final descriptor merge retains both names. I reproduced this with a two-source contract: the PR head emitted both accounts and account. Please carry placeholder provenance into the descriptors and prune after link-wide merging, or use an equivalent link-wide mechanism, and add a multi-source regression test.

[heifner]

Reproduced and fixed in 73d487b8e. Your shape was the one I had not tried — my own two-source attempt put the alias in the shared header, where both TUs instantiate it and the phantom stays suppressed. Moving the alias into one source only:

tables: [('accounts', 25660), ('account', 15140)]

You are right that this cannot be decided per-invocation, and I have stopped trying. abigen now marks the placeholder rather than suppressing it — unconditionally, so every TU emits the same descriptor and the merge is not order-dependent — and cdt-codegen prunes after the link-wide merge, beside the table_id collision check that already runs on the final ABI.

bare_table_xtu is the regression: the struct in a header, the alias and contract in one source, a second source that only includes the header. Its second TU lives in a subdirectory so the suite does not discover it as a test of its own, and it is passed through compile_flags along with an explicit -contract, since auto-detection needs a single source.

The provenance flag rides in the .desc. I had talked myself out of that on a misreading of CLAUDE.md — it says treat such a change as breaking until proven otherwise, which is a burden of proof, not a veto, and .desc is an internal artifact produced and consumed by one toolchain version and never committed. The thing that actually needs proving is the emitted ABI, and that is unchanged: 44/44 wire-sysio artifacts byte-identical.

[huangminghuang]

[P1] f64 is now serialized uninitialized

Removing this initializer leaves newly emplaced rows with an indeterminate f64: both set and mod accept an f64 argument, but neither assigns it to the row. kv_multi_index::emplace then serializes the object and reads f64 for the secondary index. Please assign u.f64 = f64 and row.f64 = f64, or otherwise retain explicit initialization.

[heifner]

You are right, and it is worse than a style regression — thank you for catching it. Neither set nor mod ever assigned f64, so the initializer was covering a pre-existing omission; removing it left an indeterminate double being serialized and used as the "byf" secondary key. That is undefined behaviour producing a nondeterministic index key, in a toolchain whose first stated requirement is deterministic output.

The deeper mistake was choosing the wrong workaround. The guide I wrote for #111 lists three ways past the complete-class problem and calls constructing-the-table-in-the-action the smallest change; I took the third — dropping initializers — the only one with runtime semantics, because it was the smallest diff.

Fixed in 73d487b8e: initializers restored, the table constructed per action instead of held as a member (which is what actually defers the instantiation past the class body), and both actions now assign the f64 they accept. All six fields are written on emplace, all five on modify.

[huangminghuang]

[P2] Track the exact placeholder declaration instead of an ABI type-name string

t.type is an unqualified ABI name, so this set conflates distinct declarations that share that name. I reproduced a bare ns1::row plus an explicitly named table over schema-compatible ns2::row; once the generated table for the first type existed, this predicate silently removed the explicit archive table for the second. Please track per-entry or declaration provenance so only the placeholder created from the bare attribute can be removed.

[heifner]

Fixed, and by construction rather than by a better key. The prune only ever removes entries that abigen marked as placeholders, so an explicitly named table can never be removed by a row struct that happens to share its ABI type name — which is what your ns1::row / ns2::row case exercised.

Checked directly: a bare ns1::row under multi_index<"live"_n, ...> beside an explicitly named ns2::row under multi_index<"archive"_n, ...> now gives [('archive', 24526), ('live', 30214)] — both survive, correctly named.

Worth noting the underlying ambiguity you point at is still there and is not mine to fix here: two distinct C++ types sharing an unqualified name both serialise as one structs entry, so the ABI cannot tell them apart regardless. The prune no longer depends on telling them apart.

[huangminghuang]

[P1] Preserve kv_key metadata when suppressing the phantom entry

The early continue drops the entire annotated ctable descriptor, including metadata supplied by sysio::kv_key. In a base-versus-head fixture using a bare table with sysio::kv_key("abi_key"), the real kv::table entry changed from the logical overridden key_names value to the physical key field name. That silently changes the ABI used by clients and SHiP key decoding. Please merge the annotated metadata into the generated table before suppressing only the phantom entry, and cover this combination with a regression test.

[heifner]

Confirmed and fixed. kv_key is resolved into key_names/key_types on the ctables path (abigen.hpp:315), so dropping that entire entry took the override with it.

The prune now folds key metadata into the survivor before discarding the placeholder, rather than dropping the entry whole. bare_table_kv_key pins it — a bare attribute plus [[sysio::kv_key("abi_key")]] over a kv::table<"realname"_n, phys_key, val>:

realname 46377 key_names=['account_id']

the logical override, not the physical raw_id. Removing the prune fails it.

[huangminghuang]

[P1] A marked entry can also represent a real same-name instantiation

abigen::to_json inserts the annotated ctable before auto-detected tables in a set keyed by table name. With a bare account row instantiated as both multi_index<"account"_n, account> and multi_index<"accounts"_n, account>, the exact-head descriptor therefore contains a marked account entry that also carries the real account table metadata, plus an unmarked accounts entry. This loop treats accounts as proof that the marked entry is superseded and deletes the live account table. I reproduced the final ABI containing only accounts, although the contract writes both tables. Multiple table names over one row type are already used in exclude_from_abi.hpp, so the descriptor needs to preserve whether a marked entry was also matched by a real same-name instantiation; add a two-table regression fixture.

[heifner]

Reproduced and it is the worst of the four — the contract writes two tables and the ABI described one:

multi_index<"account"_n,  account>   // same name as the row struct
multi_index<"accounts"_n, account>
-> tables: [('accounts', 25660)]

Your diagnosis is exact: the by-name set merges the placeholder with the same-named instantiation, so the marked entry is the live table, and the prune then reads accounts as proof it was superseded.

Taken with the other three, I have retired the provenance approach rather than patch it — 160d393bf. A marked entry cannot be told apart from a real one by anything that survives into the descriptor, and making it sound needs a qualified declaration identity in both entry kinds plus descriptor versioning. No entry is emitted for a bare attribute at all now: each instantiation emits its own, which is where the name, table_id and key layout come from anyway, and nothing is removed later so nothing can be removed wrongly.

bare_table_two_names is your case, expecting both ('account', 15140) and ('accounts', 25660).

[huangminghuang]

[P1] The kv_key fold remains incorrect and the new fixture bypasses it

A supported nested override still fails at the exact head: put abi_key { account_id } inside the bare-attributed value row, use phys_key { raw_id } as K, and instantiate kv::table<"realname"_n, phys_key, val>. add_table resolves the nested override, while add_kv_table searches only the enclosing context and emits the physical metadata. The descriptor has marked val with key_names=[account_id] and real realname with [raw_id]; this fill-only condition refuses to apply the explicit override, then deletes the marked entry, so the final ABI contains [raw_id]. The committed fixture declares abi_key as a sibling, which add_kv_table already resolves, so it passes without exercising this branch. Explicit kv_key metadata must override auto-derived metadata, with a nested-key regression test.

[heifner]

Confirmed, and the fixture criticism lands hardest — mine declared abi_key as a sibling, which add_kv_table already resolves, so it passed without touching the branch. That is the exact failure I have been flagging in other code this week.

Reproduced with the nested form: key_names=['raw_id'], the physical key.

Fixed at the source rather than in the fold. add_kv_table searched only the enclosing context while add_table, reading the same attribute, searched nested types first and then the enclosing one. They now search in the same order. Two things came with it: the override struct is inserted into kv_key_structs so validate_struct cannot prune it, as the other path already did for its own; and a kv_key naming a struct that resolves to nothing now warns instead of silently falling back to the physical key.

kv_key_nested pins the nested case, and bare_table_kv_key stays for the sibling one.

[huangminghuang]

[P2] Matching on the unqualified ABI type still conflates distinct declarations

The prior identity issue is only partially fixed. I reproduced an uninstantiated bare ns1::row beside an explicitly named ns2::row table called archive, using identical schemas so both legitimately map to ABI type row. The descriptor contains both entries, but this comparison mistakes archive for an instantiation of ns1::row and removes the bare row entry. The final ABI contains only archive, contradicting the stated rule that an uninstantiated placeholder survives. Please carry a hidden qualified declaration identity or equivalent provenance in both annotated and auto-detected entries instead of deciding from the lossy emitted type string.

[heifner]

Reproduced — [('archive', 24526)], the uninstantiated ns1::row deleted, which contradicted the guarantee I had claimed for that design. That is what decided it: the one case provenance was chosen to preserve, it did not preserve.

Rather than carry a qualified identity through both entry kinds, nothing is removed at all now. bare_table_namespaces keeps your case, and its comment says the expected result — archive alone — holds because ns1::row is never instantiated and so contributes no table, not because anything was matched and deleted.

You are right that the underlying ambiguity remains: two declarations sharing an unqualified name still collapse to one ABI type. Nothing now depends on telling them apart.

[huangminghuang]

[P2] Pre-marker descriptors are silently treated as real after an incremental toolchain upgrade

The .desc schema has no version or invalidation stamp, so a normal incremental build can mix an old object/descriptor with a TU rebuilt by this CDT. For example, an old a.cpp.desc contains the unmarked bare account phantom; a newly rebuilt z.cpp.desc contains the marked placeholder plus real accounts. Sorted merging keeps the old unmarked account, this predicate classifies it as real, and the final ABI again contains both account and accounts. Contract build rules do not inherently recompile every unchanged object when the compiler at the same path is upgraded. Please version/reject incompatible descriptors or otherwise force pre-marker descriptors to regenerate.

[heifner]

Fixed by removal — there is no marker any more, so there is nothing for a stale descriptor to be missing. Your point stands on its own though: .desc has no version or invalidation stamp, and an incremental toolchain upgrade can mix descriptors from two compilers. That is a live hazard for any future descriptor change, and I did not want a fix that depended on it.

While regenerating fixtures this surfaced something separate, which I have left for its own PR rather than widening this one: singleton_contract loses ('tbl_config', 8868). That entry was itself wrong — named after the row struct, at an id the singleton does not store under — and removing it exposes that no sysio::singleton has ever produced an ABI table entry. The visitor matches "singleton", but sysio::singleton is an alias for kv_singleton, so the specialization name never matches. Six singletons in that fixture, zero entries, before this change and after. Fixing it would ADD entries to every contract using a singleton, so it wants its own verification.

toolchain 49/49, ctest 33/33 with integration on, 16/16 integration suites, 44/44 wire-sysio artifacts byte-identical. Restoring the placeholder fails 6 of the 49.

[huangminghuang]

Re-reviewed at 4349eacd. The previous unused-annotation/live-table collision is fixed. The inline findings below remain reproducible against binaries built from this exact head.

[huangminghuang]

[P1] Preserve the scoped-table key prefix when applying kv_key metadata

This replaces the complete key layout, including the scope:name prefix that add_kv_table(..., scoped=true) already added. At this head, two kv::scoped_tables over a row with [[sysio::kv_key("logical_key")]] produce descriptors with [scope, account_id], but the final ABI contains only [account_id]. Clients therefore encode a different key from the runtime. Please preserve the existing scope prefix when applying the logical fields (and cover the scoped + superseded-annotation case).

[heifner]

Reproduced (desc [scope, account_id] → abi [account_id]), and it was never confined to kv::scoped_table.

The annotation describes the row's logical key; whether a table carries a scope in front is a property of the table, which is why add_kv_table composes [scope] + logical. The prefix is kept now unless the annotation supplies one itself — a [[sysio::kv_key]] with no argument is [scope][primary_key].

The wider case is already in the repo: named_table_attr's first and second are kv_multi_index tables over a row with an override, and their committed layout had the same scope missing. Fixed with it. kv_key_scoped pins your case.

[huangminghuang]

[P1] Emit the selected kv_key type closure

This protects the override from pruning but never emits the override struct or calls add_type for its fields, unlike the named-annotation path. A bare [[sysio::table, sysio::kv_key("abi_key")]] whose abi_key contains a custom logical_id builds with key_types:["logical_id"], while neither abi_key nor logical_id appears in structs. The resulting ABI has an unresolved key type, so query-key decoding fails.

[heifner]

Confirmed — protecting a struct from pruning does nothing when it was never added. Your shape reproduces: key_types: ["logical_id"] beside structs: [phys_key, test, val]. The struct is emitted and its fields run through add_type now, as add_table's identical branch always did.

Worth adding: the bare attribute is what makes it reachable. add_table returns as soon as it sees an unnamed [[sysio::table]], so the override never reaches the branch that would have declared it and add_kv_table is the only path left resolving the attribute — which is why the named fixtures never showed it.

kv_key_type_closure pins it; bare_table_kv_key and kv_table_explicit_key gain the struct they had been naming. Also guarded wrap_decl(nullptr) for a non-class V.

[huangminghuang]

[P1] Treat direct contract fields as ownership of the specialization

defined_in_contract() only matches the specialization itself or a TypedefNameDecl; it never recognizes a FieldDecl whose type is that specialization. An exact-head contract with directly used members singleton<"scalar"_n, uint64_t> scalar; and singleton<"plain"_n, plain_row> plain; builds successfully but emits tables: []. The new fixture's member is admitted only because its row is annotated, so it misses direct scalar and unannotated-row members.

[heifner]

Confirmed at 4349eacd — both your cases give tables: [], a contract that builds clean and describes none of its state. Matched on DeclaratorDecl now, so a static data member counts too.

You are right about the fixture: member_inst's row is annotated, so it was admitted by the other arm of the || and could never tell whether the member itself was recognised — it documented the gap instead of catching it. singleton_decl_forms gains scalar_inst and plain_inst, neither row annotated and neither named by an alias.

[huangminghuang]

[P1] Translate ABI-representable container singleton payloads

singleton<"values"_n, std::vector<uint64_t>> is valid runtime contract code, but this new discovery path now hard-fails abigen because the canonical specialization is rendered as vector. The ABI serializer accepts the corresponding uint64[] spelling, so this is representable. The fail fixture currently codifies a compatibility regression; please translate canonical containers (or otherwise retain enough sugar) rather than rejecting them.

[heifner]

Agreed — the fail fixture was pinning a limitation of the translation, not of the ABI. Retired.

A template argument is canonical and translate_type()'s container branches need a TemplateSpecializationType, so the same std::vector<uint64_t> gave uint64[] as an action parameter and the record name vector as a row. The guard then caught vector, correctly, and reported the row rather than the missing sugar. Rebuilding the sugar puts both on one path: uint64[], uint64?, pair_uint64_uint64[], uint64[4], row[].

Three limits, each of which cost a defect to find — my first attempt at this shipped two of them, and a pre-push review caught them:

• Not variant or tuple. Their canonical arguments are one Pack, which get_template_argument() does not handle: it reaches CDT_INTERNAL_ERROR and terminates the compiler. Off the whitelist they keep the old path and are refused with a diagnostic — abigen-fail/variant_row pins that, since turning a diagnostic into an abort is the opposite of what this PR is for.
• Leading arguments only. The container helpers in gen.hpp decide by counting < in getAsString(), so a vector rebuilt with its allocator printed vector<unsigned long, allocator<unsigned long>>, read as nested, and reached add_struct() — which synthesised a struct over an __vector_base_… the document never declares.
• One level. Nesting is left canonical and refused (abigen-fail/nested_container_row). The machinery that names B_vector_uint64_E runs off that same printed form and declares the typedef the name needs; a half-resugared type slipped past it and published B_vector_uint64_E[] with types empty.

validate_struct also strips the suffix, or the struct behind row[] is pruned. fixed_bytes<7> keeps the guard honest.

[huangminghuang]

[P1] Distinguish a known zero table_id from an absent ID

The preceding t.table_id != 0 check omits real ID zero, although the hash returns an unrestricted uint16_t. Valid names "rzy2"_n and "s3hm"_n both compute to zero; a contract containing both builds and emits both entries without IDs. Final collision validation then skips both (and, because its secondary loop is nested under has_key("table_id"), skips their secondary IDs too), even though both live tables alias runtime ID 0. Track presence separately and serialize a known zero.

[heifner]

Confirmed — the pair builds and links silently, both entries shipping with no table_id, which is exactly what that check exists to prevent. Presence is tracked separately from value; absence still has to be representable, since a table an annotation declares carries no id, so it is a flag rather than another sentinel.

Your second point is fixed with it: the secondary-index loop was nested under the table's own id, so a table without one took its indexes out of the check too — reachable through any declared table, no zero required.

table_id_zero and abigen-fail/table_id_zero_collision.

[huangminghuang]

[P2] Do not discard same-TU duplicate annotation targets

Because this set comparator uses only name, two different rows carrying [[sysio::table("alias")]] collapse before link-wide resolution. With physical tables first and second, exact-head output silently renames only the first to alias, leaves the second raw, and emits no collision diagnostic; swapping declaration order changes which row owns alias. Keep (name,row) entries (or diagnose failed insertion) so the resolver can reject the ambiguity deterministically.

[heifner]

Confirmed: ['alias', 'second'] at 4349eacd — first renamed, second kept its parameter, nothing reported. Keyed on (name, row) both survive, and they are refused together, each warning naming the other row.

Chasing it across translation units turned up a second half. The merge identifies annotations by name like every other section, so two differing records under one name were Error, ABI structs malformed : xshared already defined — a dead link rather than a diagnostic. It needs a header per TU: in a shared header the per-TU set drops one of the pair first and the merge has nothing to reconcile, which is how my first attempt at the fixture passed on the broken code. Annotations merge by (name, row) now.

[huangminghuang]

[P2] Resolve the complete rename graph before mutating taken

This decision is order-dependent because a later successful rename can free a name that an earlier annotation was refused. For physical alpha/bravo, with annotations alpha -> bravo and bravo -> charlie, processing bravo first yields {alpha,charlie}, while processing charlie first frees bravo and yields {bravo,charlie}. Cross-TU annotation order follows descriptor merge order, so identical declarations can produce different ABIs. Preflight the whole rename graph or resolve to a deterministic fixed point.

[heifner]

Confirmed, and the order is the merge's. Two descriptors, alpha/a_row asking for bravo and bravo/b_row asking for charlie, at 4349eacd:

merge order p,q -> ['alpha', 'charlie']
merge order q,p -> ['bravo', 'charlie']

In one TU it is not order-dependent — the set sorts by name — so it takes the merge to supply the order, meaning the answer turned on filenames.

Resolved to a fixed point now: refuse the ambiguities, then sweep until a sweep changes nothing. A target held by a table that is itself renamed away comes free, so the chain reaches {bravo, charlie} from either end; targets are unique by then, so nothing races. A cycle never comes free and gets the ordinary occupied-name warning — the ABI cannot express the swap either.

named_table_rename_chain, in one TU and split across two.

[huangminghuang]

[P2] Copy ____row when accepting a rowless descriptor

This declares a missing ____row compatible, but the richness-copy list below contains only table_id, key arrays, and secondary indexes. If a stale/older rowless descriptor is merged first, the current descriptor's row marker is discarded; resolution then treats the surviving annotation as uninstantiated and emits a phantom declaration beside the physical table. Reversing merge order renames correctly. Add ____row to the fill list (and ideally version/invalidate the descriptor schema).

[heifner]

Confirmed and fixed — ____row was the one key compatible() forgives the absence of that the fill list did not restore. At 4349eacd:

rowless first -> [('cfg', None), ('cfgtbl', 49879)]
marker  first -> [('cfg', 49879)]

One thing worth passing on: cdt-codegen sorts its descriptor list, so merge order is filename order and passing --desc-file the other way round changes nothing. My first draft of the test passed both cases on the broken code because of it.

On versioning I have not acted, and I would rather say so than leave it implied: it is a general hazard, not specific to this key, and adding a compatibility surface here would ship one with a single caller and no way to exercise the incompatible path. tests/unit/abimerge_tests.sh pins the instance instead, with hand-written descriptors — the toolchain tester builds everything with one toolchain and can never produce the mixture.

[huangminghuang]

[P2] Do not publish decoded hash text for non-record _i rows

A scalar row has no declaration on which to place the annotation used to recover an _i literal's source spelling. At this head, singleton<"singleton_builtin_long_name"_i, uint64_t> emits the ABI table name z4pypstb1k13h (with the correct ID 296), so name-based discovery and generated clients cannot address it by the declared name. Preserve the literal spelling through another channel or diagnose this combination instead of publishing a fabricated name.

[heifner]

Fixed by recovering the spelling rather than diagnosing — it is still in the AST and I had not looked.

A specialization over such a row reaches the ABI only through the contract member naming it, and that member's TypeSourceInfo holds the literal as typed. Every member is tried, since one written through an alias declared outside the class carries no arguments of its own.

Two corrections a pre-push review forced, both worth stating because the first is worse than the bug:

• The recovered text now has to hash back to the parameter. Adjacent literals are spliced by the compiler and not by the lexer, so "con" "cat"_i read as cat — a plausible name sitting at concat's table_id, which is worse than the garbage it replaced. A mismatch falls back to the decoded raw: unusable, but visibly so.
• The gate was "the row is not a class" standing in for "the row cannot carry [[sysio::table]]". std::string, sysio::checksum256 and every container row are classes the author does not own, and all of them still published decoded hashes. Gated on the attribute now.

That gate is also what keeps the annotation path exclusive: a row carrying the annotation is admitted by it alone, so a TU that never names the specialization would recover nothing and two descriptors would call one table different things. _n is untouched — there the raw is the name.

[huangminghuang]

Re-reviewed at 7c422b38. The prior findings' targeted fixes now pass, and exact-head validation passed all 68 toolchain tests, both ABI-merger tests, and all three changed examples. The inline cases below remain reproducible; several generate ABIs the chain cannot load or key layouts that do not match storage, so I cannot approve this head.

[huangminghuang]

[P1] Keep physical scope independent of logical field names

For a kv_multi_index row whose kv_key override is { name scope; }, this treats that logical field as though the annotation already supplied the physical scope prefix. At this head the ABI becomes key_names:["scope"] / key_types:["name"]; it must be physical scope:name followed by logical scope:name, i.e. two entries. The query key is otherwise eight bytes shorter than storage. Please preserve scope from table-kind/provenance rather than inferring it from a field name; the new scoped_table fixture passes only because add_kv_table already composed its suffix.

[heifner]

Agreed, and gone further than asked: the fold is deleted.

You are right that the prefix must not be inferred from a field name, and once that is accepted there is nothing left for the fold to do. Every table's own path already knows its layout — add_kv_table resolves the attribute and composes [scope] + logical, add_table takes it from the table kind — so re-deriving it from the annotation was reconstructing something already correct, by the one means that cannot be made correct.

A kv_multi_index now publishes ['scope','primary_key'] / ['name','uint64'], which is what it stores. The annotation still carries the metadata for a table it declares, since that one has no instantiation to take a layout from.

[huangminghuang]

[P1] Include key types in applied-override detection

This suffix comparison can match a physical field and a logical override solely because their names coincide. With logical { name primary_key; }, the existing physical primary_key:uint64 is considered already applied, so the final ABI remains [name,uint64] instead of [name,name]. That changes how clients represent and encode the key. Compare both key_names and key_types (including lengths), not names alone.

[heifner]

Confirmed — ['scope','primary_key'] / ['name','uint64'] where the logical key is {name primary_key}, so the type is wrong as well as the position.

Fixed by the same deletion as the sibling finding: the suffix comparison existed only to spot an override the table had already applied, and with the fold gone there is nothing to spot. Neither helper survives.

[huangminghuang]

[P1] Retain enum definitions referenced by container rows

This accepts singleton<"enums"_n, std::vector<state>> because state is present in _abi.enums, but the later enum-pruning check compares the table's full state[] spelling directly with state. Exact-head output therefore contains table type state[] and no enums section, and chain ABI validation rejects the unresolved type. Apply the same element/suffix normalization when deciding which enums to emit, and cover an enum-container row.

[heifner]

Reproduced — table type state[] with enums: [].

Not fixed, though; container rows are no longer described at all. A table row is a struct the contract declares, and std::vector<state> is refused with a diagnostic naming the row.

That is the rule upstream has always had — its add_table() takes the row's CXXRecordDecl and dereferences it — and three rounds of findings on this branch were the argument for keeping it: a scalar row crashed the compiler, containers needed sugar reconstruction that mis-declared the nested ones, variant/tuple aborted on a canonical argument pack, and binary_extension produced a type the chain refuses. Each is one struct away from a shape that works. Narrowing removed 687 lines.

abigen-fail/row_must_be_a_struct covers seven shapes including this one; docs/abi-tables.md writes the rule down.

[huangminghuang]

[P1] Do not admit a binary extension as a root table type

singleton<"ext"_n, binary_extension<uint64_t>> now succeeds and emits table type uint64$. The chain only removes $ while validating struct fields; table types go directly through _is_type, so set_abi rejects this document. binary_extension is a trailing-field marker, not a valid top-level row spelling. Please reject this row shape during abigen (or otherwise emit a representation the chain can actually validate).

[heifner]

Confirmed, and refused now rather than represented — binary_extension is one of the seven shapes in abigen-fail/row_must_be_a_struct. You are right that it is a trailing-field marker and not a row spelling; the same is now true of every non-struct row. See the sibling finding for the reasoning and docs/abi-tables.md for the rule.

[huangminghuang]

[P1] Include table specializations used only inside actions

A valid action that directly constructs and writes singleton<"local"_n, uint64_t> has no class alias/member and no row annotation. The visitor reaches this specialization, but defined_in_contract() scans only contract_class->decls(), so this condition rejects it and the exact-head ABI has tables:[] despite live state. Please associate local declarations with their enclosing contract method (or diagnose unsupported use) rather than silently omitting the table.

[heifner]

Confirmed, and left as a documented limitation rather than fixed.

defined_in_contract() reads the contract class's own declarations, which is exactly what upstream does — so this is not a divergence a porting contract would hit. Your example is also narrower than it looks now: the row must be a struct, and a local table over an annotated struct row is admitted by the annotation. What remains unseen is a local table over an unannotated row.

Detecting it means either walking method bodies in a pre-pass or warning on every unadmitted specialization in the TU, which would fire on other contracts' tables and on library code. For a shape with two one-line fixes — declare it in the class, or annotate the row — that is not a trade I want to make. Both are in docs/abi-tables.md, which now says plainly that a table declared only as a local, over an unannotated row, is not described.

[huangminghuang]

[P1] Compare key and index metadata before declaring tables identical

Two kv::table<"same"_n, K, uint64_t> specializations with different key structs have the same name, ID, type, and empty row marker, so this returns silently. I reproduced K1{id:uint64} followed by K2{owner:name}: compilation emits no warning and the ABI keeps only the first key layout. That is exactly the silent collapse this helper is meant to catch. Include key_names, key_types, and secondary_indexes in compatibility, or merge only demonstrably equivalent metadata.

[heifner]

Confirmed and fixed — it compared identity and not what the entry describes, so two kv::tables over one row differing only in the key struct matched on all four fields and the published layout came down to declaration order.

Key names, key types and secondary indexes are compared now, and the diagnostic names what differs rather than just that something did:

warning: two different tables are both called 'same': table_id 6122 over 'c::row' keyed on (id),
and table_id 6122 over 'c::row' keyed on (owner); the ABI can describe only one, and the second
is not described

table_name_collision pins it, and pins that one table instantiated in two actions stays silent.

[huangminghuang]

[P1] Recover _i spelling on the kv::table path too

kv::table<"long_table_name"_i, key, uint64_t> cannot carry a row annotation, and this still decodes the DJB2 raw as a Wire name. Exact-head output calls the table d4ntagmflkvng rather than long_table_name, leaving generated clients unable to address the intended name. Pass the written _i spelling into add_kv_table as the singleton/global path now does, or reject the unrepresentable case.

[heifner]

Not fixed by recovery — the source-text recovery is deleted, on both paths.

You had already shown it reads the lexer's tokens rather than the compiler's, and your other finding on escapes closed the argument: "con" "cat"_i recovered cat and "config\x31"_i recovered nothing. An _i name comes from [[sysio::table("name")]] on the row struct, as #115 established, and the row rule guarantees there is always a struct to put it on.

Your specific case is refused outright now for a different reason — its row is uint64_t. With a struct row and the annotation, kv::table<"long_table_name"_i, key, row> publishes long_table_name, which hash_id_table and examples/hash_id_example both cover.

[huangminghuang]

[P2] Read the evaluated literal bytes, not raw source text

Raw text neither decodes escapes nor reliably covers concatenated/raw literals. singleton<"config\x31"_i, uint64_t> compiles here but publishes ...h1giniby.g instead of config1; the checked-in adjacent-literal case likewise intentionally falls back to a decoded hash. The AST StringLiteral already has the cooked bytes that produced the template value. Use those and verify the hash, or emit an error instead of a successful ABI with an unusable name.

[heifner]

Confirmed — ...h1giniby.g rather than config1, and you are right that the cooked StringLiteral bytes are the correct source.

The recovery is gone instead. Reading source text was the wrong mechanism, and it existed only to name tables whose rows cannot carry an annotation — rows that are no longer supported. _i names come from the annotation, which is exact and needs nothing recovered. The hash check I added last round goes with it.

[huangminghuang]

[P1] Merge duplicate annotation metadata instead of keeping the first

The same (name,row) can legitimately be empty in one descriptor and resolved in another: e.g. a shared row names a forward-declared logical_key, one TU only sees the declaration, and another completes it as { uint64_t account_id; }. This seen set discards whichever record sorts second. I reproduced the final table keeping physical keys when the empty descriptor sorts first and getting account_id when the rich descriptor sorts first. Fill missing key metadata per field and reject conflicting populated records, as table merging already does.

[heifner]

Confirmed and fixed. Key metadata is filled per field now, and two populated records that disagree are refused the way table merging refuses them, rather than one of them being kept because it sorted first.

unit/abimerge_tests.sh pins it in both orders, with the empty descriptor first and the resolved one first. It needed a per-case directory to do that: cdt-codegen sorts its descriptor list, so merge order is filename order and passing --desc-file the other way round changes nothing.

[huangminghuang]

[P2] Apply satisfiable rename cycles atomically

With physical alpha/A annotated to bravo and physical bravo/B annotated to alpha, both requests remain pending because each desired name is currently taken. Yet the requested final mapping is unambiguous and ABI-valid: alpha/B and bravo/A, with unique names and the original IDs. Exact-head output warns and ignores both annotations. Build and validate the complete target mapping first, then apply unique-target SCCs/permutations together rather than requiring a transiently free name.

[heifner]

Confirmed — both refused, and you are right that the mapping is unambiguous and ABI-valid.

Left refused, deliberately. Applying it needs the complete target mapping built and validated, then SCCs applied together — real machinery for a contract that renames alpha to bravo and bravo to alpha in one link. The warning says the name is taken, and giving one of them a different name resolves it.

Recorded under "Not fixed here" rather than left implied. If a real contract turns up wanting it I would rather add it then, with that contract as the fixture.

[heifner]

Change of direction: narrowed to one rule

Stepping back from the last round rather than working through it. Three rounds of findings had gone into making abigen describe every row type C++ allows, and comparing with upstream Antelope CDT says not to — its add_table() takes the row's CXXRecordDecl and dereferences it, so a non-struct row was never supported there either.

A table row is a struct the contract declares. A scalar, std::string, sysio::checksum256, fixed_bytes<N>, any container, variant, tuple and binary_extension are refused with one diagnostic naming the row and the fix. Keeping upstream's rule means a contract ported from another Antelope chain behaves here exactly as it did there, and the struct is what makes an entry self-describing — a table's rows are named fields, not a bare scalar whose shape lives only in the C++.

Narrowing removed 687 lines net, and closed most of the round by deletion rather than by fixing:

Finding
enum container rows, binary_extension root type	row is not a struct — refused
_i on the kv::table path, cooked literal bytes	source-text recovery deleted; _i names come from the annotation
scope prefix from provenance, key types in override detection	the kv_key fold is deleted; each table's own path already knows its layout
key/index metadata in the collision compare	fixed — and the diagnostic now names what differs
duplicate annotation metadata	fixed — filled per field, conflicts refused
local-only tables, rename cycles	documented limitations, both matching upstream

docs/abi-tables.md writes the rule down with every supported declaration form, the _n/_i naming rules and the diagnostics. Legacy multi_index and singleton stay first-class — they are the transition path, and singletons vanishing was a Wire regression (upstream eosio::singleton is a real class template; sysio::singleton became an alias over kv_singleton the visitor never matched).

One deliberate break: singleton<"cfg"_n, uint64_t> compiled before and described nothing, so a contract relying on it already had an ABI that did not describe its state. It is an error now. singleton_contract is the in-tree example, with its sysio::name payloads wrapped in a struct.

Toolchain 63/63, ctest 34/34, eleven mutations each failing only its own fixtures. wire-sysio: 38/38 artifacts byte-identical to a toolchain built at 4349eacd — it uses no singleton, no _i, no [[sysio::kv_key]] and no container row, so none of this reaches it.

Thanks for the depth on these — the last two rounds are what made the case for narrowing rather than continuing.

[huangminghuang]

Re-reviewed at cf21f64. The previous scope/type, row-shape, table-collision, and annotation-merge fixes pass their exact-head tests, but the two inline cases still produce incorrect ABIs. The previously reported action-local table omission also remains reproducible for a supported struct row (cdt-cpp exits 0 with tables: []); documenting that limitation does not make the generated ABI complete, so I cannot approve this head.

[huangminghuang]

[P1] Preserve merged kv_key metadata for live tables

After merge_table_annotations() enriches an annotation from another TU, this block deliberately ignores it whenever by_row contains an instantiated table. Exact-head two-TU repro: the instantiating TU sees logical_key only forward-declared and emits table keys raw_id:uint64 plus an empty rows annotation; a second TU completes it as logical_key { name owner; } and emits owner:name. Finalization renames the table to rows but leaves key_names:["raw_id"] / key_types:["uint64"], silently dropping the explicit logical schema. The new merger test has tables:[] on both sides, so it only covers annotation-declared tables. Preserve enough table-kind/provenance to apply merged overrides to live kv::table/scoped_table entries without reintroducing scope inference from field names.

[heifner]

Reproduced exactly — the merged annotation carries ['owner'], the live table keeps ['raw_id'], and the rename lands on top of the wrong layout.

Fixed by refusing rather than repairing: an unresolvable [[sysio::kv_key]] is now an error in the translation unit that instantiates the table.

That TU is the one whose key layout reaches the ABI, so it is the one that has to resolve the override, and it was already warning twice that it could not:

warning: kv_key struct 'logical_key' not found; the physical key's field names will be used in the ABI

It just wasn't loud enough to stop a build that then published a layout the author did not ask for.

I went that way rather than preserving provenance because the alternative is to carry the physical key's shape through the descriptor and reason about which leading fields are physical — which is exactly the machinery removed this round, after it got that question wrong twice (a logical field named scope suppressing the physical one, and a suffix compared by name alone). A forward-declared key struct completed in a different translation unit is a missing include, and the fix belongs there.

abigen-fail/kv_key_not_visible pins it, and docs/abi-tables.md states the rule.

[huangminghuang]

[P2] Cook annotation literals before using them as _i names

This assumes the row annotation is an exact naming channel, but optional C++11 attribute arguments are still extracted from one raw lexer token in sysio_attrs.cpp. At this head, matching annotation/template pairs using "config\\x31" compile successfully to the literal ABI name config\\x31 at the table ID of cooked config1; adjacent "con" "catenated_long_table" emits con at the ID of the full concatenated string. Both tables are therefore mislabeled despite providing the required annotation. Parse the evaluated StringLiteral (or reject a name/ID mismatch), and cover escapes plus adjacent literals.

[heifner]

Confirmed, and it lands on a claim I made in this thread — I told you the annotation was an exact channel, and it is not. Reproduced both:

[[sysio::table("config\x31")]]                 -> 'config\x31'  at id 62258 (= cooked config1)
[[sysio::table("con" "catenated_long_table")]] -> 'con'         at id 34466 (= the concatenation)

Chasing it turned up a third, from the other end of the same pipeline: the argument is encoded into an AnnotateAttr as sysio_table(arg) and split back out on [\s,]+, so [[sysio::table("has space")]] published has. Truncated by the encoding rather than by the lexer, and silent for as long as the attribute has existed.

Refused rather than cooked, though — config\x31 is not a name we want to carry. The argument must be one plain string literal, and the name letters, digits and underscore. These travel out through the ABI into wire-sysio, SHiP and Hyperion, and a name worth having is one that can be written plainly. All 88 annotation names in wire-sysio and all 52 in this repo already satisfy it, so nothing existing moves. _i still lifts the 13-character limit — the name is hashed, not encoded — which is the whole point of it.

compile-fail/attr_arg_not_plain covers the escape, the splice and the whitespace; abigen-fail/table_name_charset covers the rest. docs/abi-tables.md says it, and the sentence claiming the channel is exact is gone.

Worth noting this is pre-existing — sysio_attrs.cpp is otherwise untouched by this branch — but it became load-bearing the moment the annotation became the only naming channel for an _i table, so it belongs here.

[huangminghuang]

Re-reviewed at 5c680470. The prior escaped/adjacent-literal and cross-TU fallback repros now fail cleanly. Exact-head validation passed all 66 toolchain fixtures, all 4 ABI-merger cases, and all 8 examples. The inline cases below remain reproducible: two still accept named _i tables while silently discarding the requested name, one rejects a key definition that normal C++ lookup can see, and one breaks the existing dotted table-name alphabet. The previously reported action-local table omission also still produces tables: [], so I cannot approve this head.

[huangminghuang]

[P1] Do not turn macro-expanded named attributes into bare ones

This validation is skipped when the whole attribute comes from a macro, because the expansion range ends at the macro invocation and the probe above does not see (. Since sysio::table has zero required arguments, that path leaves Str empty and emits a bare sysio_table annotation instead of diagnosing it. At exact 5c680470, both #define NAMED_TABLE [[sysio::table("macro_table_name")]] and a function-like NAMED_TABLE(name) compile successfully with an _i singleton, but the ABI names the table ijqvau4wut5hi (the decoded hash) rather than macro_table_name. If the macro spelling cannot be recovered under the new plain-literal policy, reject it rather than silently dropping its argument.

[heifner]

Confirmed — ijqvau4wut5hi instead of macro_table_name, the argument dropped and the attribute read as bare.

Supported rather than rejected, in the end. I went looking for whether the spelling was recoverable before deciding, and it is: the expansion range ends at the invocation, but the argument is still sitting at the spelling location inside the macro body. So the probe falls back there when the expansion has nothing, and an object-like macro now carries its name through:

#define NAMED_TABLE [[sysio::table("macro_table_name")]]   ->  ('macro_table_name', 43674)

Your function-like case is the one that genuinely cannot be recovered — at the macro's own location the argument is the parameter, not the caller's literal — so that is refused, as you asked, with a diagnostic that says a macro parameter is the problem rather than complaining about a literal the author did in fact write.

abigen-pass/table_name_forms and compile-fail/attr_arg_from_macro.

[huangminghuang]

[P1] Validate an explicit empty name before treating it as bare

This nonempty check is unreachable for [[sysio::table("")]]: the empty argument is encoded identically to a bare attribute, and the earlier if (table_name.empty()) return; exits first. An exact-head _i singleton using that annotation compiles with exit 0 and publishes sqwcza1ug5eid at table ID 31425 instead of rejecting the missing readable name. Preserve whether an argument was supplied (or reject the empty literal in the attribute handler) so the intended validation cannot be bypassed.

[heifner]

Confirmed — an empty argument encodes identically to no argument, so if (table_name.empty()) return; fired first and the validation was unreachable.

Rejected in the attribute handler, which is the last point where "empty" and "absent" are still distinguishable. It joins compile-fail/attr_arg_not_plain with the escape, the splice and the whitespace cases, since they all come down to the same thing: the argument is read as text, so it has to be text that survives being read.

[huangminghuang]

[P1] Search enclosing scopes before reporting a key invisible

The new hard error relies on the lookup above, but that lookup checks only types nested in the value row and direct declarations in the row's immediate context. A complete namespace-scope logical_key is normally visible from a contract-nested row (an in-class alias and static_assert(sizeof(logical_key)) both compile), yet exact-head abigen exits 255 here for [[sysio::kv_key("logical_key")]]. A control with the row at namespace scope succeeds and emits owner:uint64. Use semantic lookup or walk parent declaration contexts before concluding that the definition is absent from the instantiating TU.

[heifner]

Confirmed, and this one is mine — the error I added an hour ago turned a survivable miss into a build failure on working code.

The lookup checked types nested in the row and the row's immediate DeclContext and stopped, so a row nested in the contract class could not see a namespace-scope struct. Harmless while the miss was a warning that fell back to the physical key; not harmless as an error.

It walks every enclosing scope out to the translation unit now, and both paths that read the attribute share one lookup rather than keeping two copies in step. Your exact shape is in abigen-pass/table_name_forms — namespace-scope logical_key, row nested in the class — publishing rows keyed on owner.

[huangminghuang]

[P2] Preserve valid dotted table names

This predicate rejects ., even though _n names explicitly support the .12345a-z alphabet, the existing singleton_contract fixture emits tables such as smpl.conf5, and wire-sysio defines table_def::name as a free-form string. Exact head now rejects [[sysio::table("foo.bar")]] paired with singleton<"foo.bar"_n, ...>, a previously accepted and unambiguous spelling that round-trips through the annotation encoding. Restrict characters that actually break the encoding, but retain . so existing annotated Wire names continue to compile.

[heifner]

Agreed — I picked the C++ identifier charset when the relevant alphabet is the name one. . is in .12345a-z, singleton_contract already publishes smpl.conf5, and it round-trips the encoding without trouble. Letters, digits, underscore and dot now; abigen-pass/table_name_forms carries foo.bar alongside its _n parameter.

[huangminghuang]

Re-reviewed current head 4fcc2b77. The four cases raised on 5c680470 are fixed: object-like macro names, direct C++11 empty-name rejection, dotted names, and namespace-scope kv_key lookup now behave as intended. Exact-head validation passed the 68/68 toolchain suite, 4/4 ABI-merge suite, and all eight examples.

I still cannot approve because the three exact-head repros below compile successfully while publishing the wrong table name or key schema. The previously discussed action-local unannotated table omission is also unchanged (tables: []) and remains listed under “Not fixed.”

[huangminghuang]

[P1] Skip trivia before deciding the attribute is bare

An attribute argument clause may be separated from the attribute token by whitespace or comments, but this tests only the immediate source character. At this head, [[sysio::table /* legal trivia */ ("configuration_store")]] compiles and is recorded as bare sysio_table; with singleton<"configuration_store"_i, ...>, the ABI silently publishes the decoded name sqwcza1ug5eid instead of configuration_store. Please locate the next preprocessing token (while preserving expansion/spelling handling) before deciding that no argument was supplied, and cover the trivia form with a regression.

[heifner]

Confirmed — sqwcza1ug5eid instead of configuration_store. I probed the next source character for ( where the question is the next token.

Before fixing it I checked whether the source-text path needs to exist at all, since it is the origin of this whole family. It does: clang parses arguments for the GNU spelling — getNumArgs() is 1 with a cooked StringLiteral — and not for the C++11 spelling, which reports 0 even for a plain [[sysio::table("x")]], and still reports 0 with a required argument declared. So the form every contract writes has to be read from source, and the answer is to read it properly rather than keep adjusting it.

It asks for the next token now, which skips whitespace and comments by construction, and the argument and its closing paren come from the same scan — the macro fallback and the one-plain-literal rule ride on it instead of on offset arithmetic. abigen-pass/table_name_forms carries the trivia spelling.

[huangminghuang]

[P1] Apply empty-name rejection to the GNU spelling

This check is confined to the C++11 source-text branch. __attribute__((sysio_table(""))) takes the Attr.getNumArgs() > 0 path, leaves Str empty, skips this check, and is later encoded as bare sysio_table. Exact-head cdt-cpp exits 0 and an _i singleton again publishes the decoded hash rather than rejecting the empty name. Please track whether an argument was syntactically supplied across both spellings and perform the empty check after both parsing paths.

[heifner]

Confirmed. The check sat inside the C++11 branch, and the GNU spelling takes the parsed-Expr path, so it never reached it.

Both paths record whether an argument was syntactically supplied now, and the emptiness check runs once after they converge — beside the charset check, which is the same kind of question and was already in the right place. compile-fail/attr_arg_not_plain covers both spellings.

[huangminghuang]

[P1] Honor C++ shadowing when resolving kv_key

This direct-declaration scan ignores aliases and then continues into parent scopes. In an exact-head repro, a global struct logical_key { name wrong_outer_owner; }; is shadowed inside the contract by using logical_key = actual_key;; normal C++ lookup (and a static_assert) resolves the alias, but this helper skips it and selects the global record. The build succeeds while the ABI publishes wrong_outer_owner:name instead of intended_inner_id:uint64. Please use semantic lookup, or at minimum stop at nearer declarations and resolve aliases, because climbing past a shadowing declaration can silently emit the wrong key schema.

[heifner]

Confirmed, and this is the one worth the most words back: wrong_outer_owner instead of intended_inner_id, with the build clean.

You offered semantic lookup or, at minimum, stopping at nearer declarations and resolving aliases. Semantic lookup is not available — abigen runs as an ASTConsumer in HandleTranslationUnit, and Sema is gone by then — so I have taken the second, but stated it as a rule rather than left it as an approximation:

the row, then the enclosing class, then each enclosing namespace; a struct or an alias to one; and the first scope that declares the name decides, complete struct or error.

The reason for making it a rule rather than a better approximation is your diagnosis: what caused the wrong schema was not missing aliases as such, it was climbing past a nearer declaration in search of something usable. A hand-rolled walk will never match C++ lookup — using-declarations, inline namespaces, dependent scopes are all out of reach — so anything it cannot resolve is now refused by name rather than guessed at, and the diagnostics say what was looked for, where, and what would satisfy it:

[[sysio::kv_key("nowhere_key")]]: no struct named 'nowhere_key' was found in the row, the
enclosing class, or any enclosing namespace. The key struct must be declared in one of those
-- as a struct or an alias to one -- and be complete in this translation unit

abigen-pass/kv_key_resolution pins all four sites including your shadowed alias, and docs/abi-tables.md states the rule. Nothing existing is precluded: every kv_key struct in this repo resolves from the row, the contract class or a namespace, and wire-sysio uses the attribute nowhere.

[huangminghuang]

Re-reviewed current head 5f37c2ae. The three exact repros from my prior review are fixed: direct trivia preserves the name, GNU sysio_table("") is rejected, and the contract-local alias wins over the global record. Exact-head validation passed 69/69 toolchain tests, 4/4 ABI-merge tests, and all eight examples.

I still cannot approve. The inline cases below include three paths that compile cleanly while publishing the wrong table name or key schema, plus one documented alias form whose result depends on an unrelated instantiation. Two of the newly edited regression tests also pass against the exact broken 4fcc2b77 toolchain and therefore do not pin their fixes.

Non-blocking cleanup: the plugin build now emits -Wcomment at sysio_attrs.cpp:61, and the PR description still has the pre-fix character class/test count.

[huangminghuang]

[P1] Do not treat macro-produced argument clauses as bare

findNextToken sees the unexpanded source token here, so a macro that supplies the argument clause is missed. At this head, #define TABLE_ARGS ("configuration_store") followed by [[sysio::table TABLE_ARGS]] compiles with no diagnostic, but an _i singleton publishes sqwcza1ug5eid instead of configuration_store. The same happens when a macro supplies only ( or an empty macro sits before a direct (. Since the optional-argument path interprets a missing open as bare, please either inspect the expanded tokens or diagnose an unrecoverable macro-produced clause; it must not silently discard a supplied name.

[huangminghuang]

[P1] Search all fragments of an enclosing namespace

ctx->decls() only visits the current NamespaceDecl fragment. In an exact repro, app::logical_key is defined in one namespace app {} block and the contract in a later block, with a conflicting global logical_key. This scan misses the intended namespace record, climbs to the translation unit, and cdt-cpp exits 0 while the ABI publishes the global wrong_global_owner:name schema instead of intended_namespace_id:uint64. Please perform lookup across all redeclarations/fragments of each enclosing namespace.

[huangminghuang]

[P1] Stop lookup on every nearer declaration of the name

The stated rule says unsupported forms are errors rather than guesses, but this branch ignores every same-named declaration except a record or typedef. For example, an enclosing namespace with using keydefs::logical_key; and a conflicting global struct compiles successfully and publishes the global wrong_global_owner:name schema; a nearer enum or static data member has the same result. When any nearer declaration has this name but cannot be resolved under the supported rule, set saw_name and stop with the promised diagnostic instead of continuing outward.

[huangminghuang]

[P2] Do not make alias support depend on unrelated instantiation

A visible template<class T> struct key_template { T templated_id; }; using logical_key = key_template<uint64_t>; is a concrete alias to a defined struct, but abigen exits 255 here because Clang has not yet materialized the specialization. Adding an unrelated static_assert(sizeof(logical_key) > 0) makes the same contract pass and emits templated_id:uint64. Please materialize/resolve the visible specialization before testing completeness, or explicitly exclude this form from the documented alias support; ABI generation should not depend on an unrelated ODR-use.

[huangminghuang]

[P2] Make this regression distinguish named from bare

This case uses an _n name, so if the attribute regresses to bare the fallback decoder still produces exactly foo.bar; the expected ABI is unchanged. I ran this current test against the exact broken 4fcc2b77 toolchain and it still passed 1/1, while an isolated long _i trivia case reproduced the wrong decoded name. Put the trivia on a long _i-named row (or otherwise assert the annotation) so removing the token fix changes the expected output.

[huangminghuang]

[P2] Isolate the GNU empty-name regression

This fixture already has the C++11 empty-name declaration, which emits the identical may not be empty substring, and the test runner checks only that the substring appears once. Consequently this current test passes against the exact 4fcc2b77 toolchain even though that toolchain accepts the GNU declaration. Split the GNU case into its own compile-fail fixture (or assert distinct occurrence/location data) so it actually guards the other parse path.

[heifner]

Reverting the validation I added; keeping one rule

Thirteen of the last thirteen findings were on validation added after review, and none on the seven defects this PR is for. That is a treadmill I built: each hardening step created surface, you correctly found the holes, and I hardened again — arriving at namespace fragments, using-declarations and unmaterialised template specializations. That is a name-lookup implementation, and it does not belong in this PR.

Net −655 lines.

sysio_attrs.cpp is back to master: the plain-literal rule, the empty-argument check, the macro spelling fallback and the token probe are all gone. Reading the annotation as source text is how it has always worked, and the ways it can disagree with the compiler are pre-existing and not what this PR set out to fix. Your six findings today go with it, along with the four before them.

One rule stays: a table name is letters, digits, underscore and dot. These names leave the toolchain in the ABI and are read by wire-sysio, SHiP and Hyperion, so what can appear in them is worth constraining. . is in the set because it is part of the _n alphabet, as you pointed out. It also catches the escape case for free, since a backslash is not in the set.

The kv_key lookup is a simple scan again — nested types, then the row's enclosing context — and a miss is a warning with a fallback to the physical key, as it was before. Making it an error is what made the lookup's precision matter: approximately right had been fine for years, and only a build failure turned every gap in a hand-rolled walk into a P1. Round 2's fix stays, which is the part that mattered — both paths that read the attribute search in the same order.

Five fixtures go with the code they tested. docs/abi-tables.md now separates what is enforced from what is merely how to write it.

What remains under review is the PR's actual subject: the bare-table phantom, singletons reaching the ABI at all, [[sysio::table("name")]] resolved link-wide, --use-rt, the examples, the shared-header link failure, a table_id of zero, and the row-must-be-a-struct rule that came out of your earlier rounds and removed 687 lines on its own.

Toolchain 65/65, ctest 34/34, wire-sysio 38/38 byte-identical to a toolchain built at 4349eacd.

Thank you for the persistence on these — the pattern in them is what made the case for cutting rather than continuing.

[huangminghuang]

Re-reviewed current head 60e9834a. The scope reduction removes the prior newly added validation and lookup regressions, and exact-head validation passed 65/65 toolchain tests, 4/4 ABI-merger tests, and all eight examples. Ubuntu CI is green; macOS Arm64 is still running.

I still cannot approve because the inline cases produce mislabeled or incomplete ABIs.

Please also refresh the PR description for this head: it still says non-plain table names and invisible kv_key overrides are errors, gives a character class without dot, and reports 66 toolchain tests. The revert also left implementation comments at abigen.hpp:469-470 and abigen.hpp:1365-1381 describing behavior that no longer exists.

[huangminghuang]

[P1] Validate annotations before the link-wide rename

The resolver now trusts r.ann["name"] even though the C++11 attribute handler can deliver truncated or uncooked source text. In an exact two-TU repro, a shared row uses [[sysio::table("configuration_" "store")]]; one TU only declares it and another instantiates multi_index<"configuration_store"_i, row>. Base fails on mismatched descriptors, but this head exits 0 and emits name:"configuration_" with table_id:31425, the ID of the full name, so clients cannot discover the requested table. Macro-token and whitespace variants do the same. Cook the literal or reject spellings that cannot round-trip before applying the link-wide rename.

[heifner]

Reproduced the head behaviour exactly — configuration_ published at 31425, the full name's id.

I could not reproduce base failing, though, and that matters for what to do about it. In my two-TU construction — shared header declaring the annotated row, one TU instantiating multi_index<"configuration_store"_i, row>, the other only including it — base emits configuration_ too, with no error. If you have a construction where base fails on mismatched descriptors, I would like it, because that is the difference between a regression and a pre-existing wart.

As it stands I am leaving it, and want to be plain about why rather than quietly skipping it. sysio_attrs.cpp is now byte-identical to master: reading the annotation as source text, with the truncation that implies, is how it has always worked. I added a plain-literal check for exactly this and then reverted it, along with the empty-argument check, the macro fallback and the token probe, because that validation became the entire subject of review — thirteen consecutive findings, none of them on the seven defects this PR is for. Re-adding a piece of it reopens that surface.

What did stay is the charset — letters, digits, underscore and dot — which is the constraint worth enforcing, since these names are read downstream by wire-sysio, SHiP and Hyperion. It catches the escape spelling, since a backslash is not in the set. It does not catch adjacent literals, because configuration_ is a perfectly ordinary name; distinguishing it from an intended one needs the literal cooked, which is the surface I removed.

docs/abi-tables.md says to write the name as a plain literal and why. If you can show base failing here, I will reconsider on the grounds that it is a regression rather than an inherited limitation.

[huangminghuang]

I rebuilt all four relevant tools from the exact base 2fe0822b and reproduced the failure. The distinction from a TU that literally only includes the header is that the declaration-only TU also causes abigen to emit a descriptor:

// row.hpp
struct [[sysio::table("configuration_" "store"),
         sysio::contract("adjacentxtu")]] configuration_row {
   uint64_t id;
   uint64_t primary_key() const { return id; }
   SYSLIB_SERIALIZE(configuration_row, (id))
};

// main.cpp: contract action body
sysio::multi_index<"configuration_store"_i, configuration_row> rows(
   get_self(), get_self().value);

// a_declares_only.cpp
#include "row.hpp"
[[sysio::action]] void other(uint64_t value) { (void)value; }

Exact command:

cdt-cpp main.cpp "-abigen_output=''" -contract=adjacentxtu a_declares_only.cpp

Base exits 255 with Error, ABI structs malformed : configuration_ already defined; its two descriptors contain configuration_ at IDs 6649 and 31425. This head exits 0 and publishes configuration_ at 31425. I independently reran the same construction today. Macro-token and whitespace variants show the same base-failure-to-head-success transition.

So I agree that reading the source spelling is inherited, but the resolver converting the resulting descriptor disagreement into a successful mislabeled ABI is introduced here.

[heifner]

You are right, and my earlier reply was wrong for a reason worth stating: I had been comparing against 4349eacd, an intermediate commit inside this branch, rather than the merge-base 2fe0822b. Every "base does this too" I have written in this review was measured against mid-PR code. Rebuilt at the real base, your construction reproduces exactly — base produces no ABI, head exits 0 with configuration_ at 31425.

Refused now rather than cooked. Chasing it also turned up a spelling that is not a corner case at all:

struct [[sysio::table("user_preferences_"
                      "history")]] pref_row { … };
multi_index<"user_preferences_history"_i, pref_row> t(…);

_i exists because the name is too long for _n, and a name long enough to need _i is exactly a name long enough to wrap across two lines. That published user_preferences_ at table_id 32944 — the id of the full name — so the name addressed nothing and the id was unreachable by name.

One string literal is what the reader and the compiler are guaranteed to agree on, and every sysio attribute in the tree already takes exactly one, so nothing legal is precluded. compile-fail/attr_arg_one_literal uses the wrapped-name spelling, since that is the one someone will actually write.

[huangminghuang]

[P1] Keep kv_key dependencies for annotation-only tables

[[sysio::table("declared"), sysio::kv_key("logical_key")]] is explicitly retained here even without an instantiation, but its key dependencies are not. validate_struct() checks kv_key_structs only inside the instantiated-table loop; when this annotation is the only table, that loop is empty. An exact-head repro builds successfully and publishes key_types:["logical_id"] while types is empty; base emits logical_id -> uint64, and Wire's key codec reports Unsupported BE key type: logical_id for the head ABI. Adding an unrelated ordinary table makes the typedef and key struct reappear. Preserve kv_key_structs independently of the actual-table loop and add an annotation-only typedef-key regression.

[heifner]

Confirmed and fixed. The kv_key_structs check sat inside the loop over instantiated tables and never depended on the loop variable, so with an annotation-declared table as the only table the loop never ran:

tables : [('declared', key_types ['logical_id'])]
structs: [lone_row, test]        types: []      <- both pruned

Hoisted out of the loop — the override is a dependency of the attribute, not of any one table. named_table_attr's declared row carries a kv_key with a typedef key now, since it is already the annotation-only case, so removing the hoist fails it.

[huangminghuang]

[P2] Give internal-linkage rows a TU-unique identity

____row is only the textual qualified name, which is not unique across translation units. In an exact two-TU repro, each TU defines a different namespace { struct row }, annotates it as first/second, and instantiates tables one/two; both markers become (anonymous namespace)::row. This groups the unrelated tables, emits two row type of 2 warnings, and ignores both annotations. Base emits first and second; with _i parameters the head leaves decoded hash labels. Use a stable TU-unique identity, such as a source-qualified ID or USR, for internal-linkage declarations.

[heifner]

Confirmed and fixed — that marker exists to name the same type in every translation unit, and for an anonymous-namespace struct it does not.

Qualified with the main file for internal-linkage declarations now, which is what makes it an identity rather than a printed name. Your case gives first and second with no warnings; named_table_internal_linkage pins it across two TUs.

One note on the comparison: in my construction base emits one and two as well, not first and second — I could not get base to apply either annotation for anonymous-namespace rows. The fix stands regardless, since the grouping was wrong on its own terms.

[huangminghuang]

Re-reviewed current head 139f6fc7. The production kv_key closure fix works in isolated exact-head probes, and the anonymous-namespace fixture is sensitive to the parent implementation. Exact-head validation passed 38/38 abigen-pass and 14/14 abigen-fail cases; both CI platforms are green.

I still cannot approve. The prior annotation-name finding remains a PR-introduced base-failure-to-head-success regression; I replied there with the exact construction and descriptor IDs. The two additional current-head issues are inline.

[huangminghuang]

[P1] Use a declaration-stable row identity

The main-file suffix is neither stable for a header-defined table schema nor sufficient for other local records. In an exact repro, a bare anonymous row is defined in row.hpp and both TUs instantiate the same physical multi_index<"orig"_n, row>; this head writes @main.cpp/@other.cpp into the two markers and finalization exits 255 with orig already defined, while parent 60e9834a succeeds with one orig table. Conversely, two actions in one source can each declare a distinct local annotated struct row; neither is in an anonymous namespace, so both identities remain row. Exact head then exits 0 with two ambiguity warnings and publishes decoded _i hashes instead of the requested first/second names, while base publishes both names. Key this marker by a stable declaration identity (for example spelling file plus offset or an appropriate Clang USR), so copies of one header declaration agree and separate local declarations differ, and cover both cases.

[heifner]

Confirmed, and the first half is a regression I introduced yesterday: one header declaration included by two TUs got @main.cpp and @other.cpp, and a table that had linked fine failed with orig already defined.

Your framing is the fix — the marker needs a declaration identity, not a name and not a file. It has to agree for copies of one declaration and differ for separate declarations, and the declaration's spelling location answers both without special-casing anonymous namespaces at all, so it is less code than what it replaces.

By basename rather than full path, because this toolchain really does produce ./aux/row.hpp beside aux/row.hpp for one header across two TUs — named_table_split's own descriptors show it — and that is still one declaration. Diagnostics print the name half, so the warnings are unchanged.

named_table_internal_linkage now covers both halves: the per-TU anonymous rows that must stay apart, and a shared-header row both TUs instantiate that must stay together.

[huangminghuang]

[P2] Exercise the empty instantiated-table set

This fixture has six unrelated multi_index instantiations below, so the old kv_key_structs check still executes on the first iteration of set_of_tables and retains lone_key/lone_id. I overlaid the immediately preceding 60e9834a plugin onto the current test tree and this new expected ABI still passes unchanged; the old plugin fails only when the annotation-declared table is the contract's sole table. Move this case to a dedicated no-instantiation contract so reverting the hoist actually fails the regression.

[heifner]

Confirmed — six unrelated instantiations below it, so the loop ran on the first one regardless and the hoist was never exercised. That is the fourth test of mine in this branch that passed against the code it was written to catch, which is a pattern I should be checking for rather than being told about.

Moved to annotation_only_table, a contract whose annotation-declared table is its only table, which is the shape that empties the loop. named_table_attr goes back to its own subject.

[huangminghuang]

I found a blocking row-identity collision on the current head, so I am not approving it. I reproduced it with two distinct row.hpp headers in different directories; when the row declarations have the same qualified name and byte offset, both annotations are refused and the ABI publishes the raw table parameters. Ubuntu CI is also red: 4 toolchain cases fail because the new internal identity is printed in warning text. Details are inline.

[huangminghuang]

[P1] Preserve the full file identity here. filename(...) collapses distinct headers with the same basename, and the offset does not disambiguate declarations laid out identically. I reproduced this with a/row.hpp and b/row.hpp, each declaring (anonymous namespace)::row at offset 135 with same-length table names: both become (anonymous namespace)::row@row.hpp:135, both annotations are rejected as applying to two tables, and the ABI emits the raw names one/two instead of alpha/bravo. Please normalize/canonicalize a full path (or use a stable FileEntry identity) so alternate spellings of one file agree without conflating different files.

[heifner]

Confirmed — a/row.hpp and b/row.hpp both became (anonymous namespace)::row@row.hpp:117, both annotations refused, one/two published instead of alpha/bravo.

The basename was me fixing one half and breaking the other. It was there to absorb a real spelling difference — this toolchain produces ./aux/row.hpp from one TU and aux/row.hpp from another for a single header, which named_table_split's own descriptors show — and I traded that for conflating distinct files.

real_path settles both, as you suggested: alternate spellings of one file agree, different files do not. 375ef80b.

named_table_internal_linkage now carries all three shapes, so neither half can be lost again: anonymous rows declared per TU that must stay apart, one shared-header row both TUs instantiate that must stay together, and your same-basename pair that must stay apart. Reverting to a basename fails the third; reverting to the raw spelling fails the second.

[huangminghuang]

[P2] Keep the declaration key out of user-facing diagnostics. r.row now contains the internal @basename:offset suffix, so this warning exposes values such as kv_key_scoped::val@kv_key_scoped.cpp:1968. That is also why the current Ubuntu job fails 4 toolchain tests (kv_key_scoped, named_table_duplicate_target, named_table_attr, and named_table_split). Carry a separate display name or strip the identity portion when formatting warnings; updating fixtures would cement unstable byte offsets into diagnostics.

[heifner]

Right on both counts, and thank you for tying it to the CI failure — that is exactly what it was.

Already fixed in 02e450cf, and the cause is worth recording: the display half of that change existed in my working tree but never left it. I staged with git add -A plugins tests, which does not include tools/, so the commit carried the identity into ____row without the stripping that goes with it. My local suite passed because it built the tree that had both halves.

Diagnostics print the name half now; the identity stays internal, and no fixture asserts an offset.

[huangminghuang]

I found one blocking problem in the new regression coverage, so I am not approving this head. The canonical-path implementation looks sound, and the diagnostic cleanup passes the affected cases, but the same-basename fixture currently succeeds through the annotation-only fallback after both intended physical tables are discarded.

[huangminghuang]

[P1] Give the same-basename rows unique physical table names so this test exercises the canonical-path match. This reuses "one"_n, already instantiated over row on line 48 (and other.cpp similarly reuses "two"_n). The test run emits two different tables are both called 'one'/'two' and discards each same table before annotation resolution. Consequently alpha and bravo in the expected ABI are annotation-only phantom entries—both have empty keys and no table_id—rather than renamed multi_index tables, so the fixture passes even if the new row identity never matches. Use distinct raw names in both TUs and expect scope/primary_key plus their table IDs; that also makes the stated “no warnings” condition true.