Trit.pos was fixed in #3468. TokenKind::KwFn is the same enum-member reference spelled with a path, and it was not.
Measured, whole corpus, -ferror-limit=0
- 917
X::Y occurrences in the generated C, across 65 files and 584 distinct lines. C has no :: in an expression at all.
- 666 of them are member references, 251 are calls.
- Of the member references, 538 name an enum the same translation unit declares -- so the constant
gen_c_enum emitted for it is already in the file.
- Of those 538, 526 name a variant the enum actually declares. The other 12 do not (
Trit::TRUE, Trit::NULL, PropKind::Edge) and are a separate spec defect, listed below.
Top bases: TokenKind 88, ProofStatus 74, ErrorCode 61, Kind 59, StepKind 42, PropKind 24, ContentType 23, ActionType 20.
Why C alone
gen-rust emits TokenKind::KwFn and compiles; gen-zig rewrites :: to .; gen_c_enum has been emitting TOKENKIND_KWFN all along. The declaration and this spelling of the use were never brought together -- the fourth instance in this campaign of three backends agree and one has no answer.
The 12 sites that name a member their enum does not declare
Trit::TRUE, Trit::FALSE, Trit::NULL, Trit::UNKNOWN (against an enum of pos/neg/zero), PropKind::Edge, ProofStatus::open. Lowering these would emit a constant nothing declared -- the same error with worse wording. They stay loud, and the specs are what needs fixing.
Neighbouring populations, named rather than folded in
- 477 three-segment paths in the specs (
lexer::TokenKind::RBrace), of which 23 reach the generated C. The enum is often declared in the reading translation unit, so the constant exists; the base is a module path and does not match a single-identifier key. Not attempted here.
- 251
module::fn(...) calls need a different repair (eval 36, gf16 22, constants 13).
Trit.poswas fixed in #3468.TokenKind::KwFnis the same enum-member reference spelled with a path, and it was not.Measured, whole corpus,
-ferror-limit=0X::Yoccurrences in the generated C, across 65 files and 584 distinct lines. C has no::in an expression at all.gen_c_enumemitted for it is already in the file.Trit::TRUE,Trit::NULL,PropKind::Edge) and are a separate spec defect, listed below.Top bases:
TokenKind88,ProofStatus74,ErrorCode61,Kind59,StepKind42,PropKind24,ContentType23,ActionType20.Why C alone
gen-rustemitsTokenKind::KwFnand compiles;gen-zigrewrites::to.;gen_c_enumhas been emittingTOKENKIND_KWFNall along. The declaration and this spelling of the use were never brought together -- the fourth instance in this campaign of three backends agree and one has no answer.The 12 sites that name a member their enum does not declare
Trit::TRUE,Trit::FALSE,Trit::NULL,Trit::UNKNOWN(against an enum ofpos/neg/zero),PropKind::Edge,ProofStatus::open. Lowering these would emit a constant nothing declared -- the same error with worse wording. They stay loud, and the specs are what needs fixing.Neighbouring populations, named rather than folded in
lexer::TokenKind::RBrace), of which 23 reach the generated C. The enum is often declared in the reading translation unit, so the constant exists; the base is a module path and does not match a single-identifier key. Not attempted here.module::fn(...)calls need a different repair (eval36,gf1622,constants13).