arkham: handle the comesfrom statement tag - #95
Conversation
nimony is gaining `(comesfrom SYM S*)` in nim-lang/nimony#2240: a transparent wrapper marking statements produced by expanding SYM (a template today), so the debug backend can emit them as a DWARF inlined frame. It opens no scope and has no semantics of its own. Without this every native test aborts with arkham x64n: genStmt2 comesfrom [AssertionDefect] The wrapper's first child is the origin SYMBOL, not a statement, so the four passes that walk statement children generically each step over it before treating the rest as `stmts`: - codegen_x64 genStmt2 / asmStmt, codegen_a64 genStmt2: emit the body, no `enterScope` (unlike `ScopeS` - the locals an expansion declares belong to the enclosing scope). - analyser: the generic `analyseChildren` path would analyse the leading symbol as a symbol *use* and record a read of the expanded routine here. - register_allocator: same, and it would carry that phantom read into the live ranges. Each branch sits behind `when declared(ComesfromS)` so arkham compiles both against a nimony that has the tag and one that does not. Without the guard the two repos deadlock: this PR cannot build until #2240 merges, and #2240's linux-amd64 job cannot pass until this one does. The guards can be dropped once #2240 is in.
5467c74 to
38bc037
Compare
|
CI was red because this and nim-lang/nimony#2240 were waiting on each other. Both repos check out the other's master with no
Neither could go first. Now each branch sits behind Verified both ways against a clean checkout:
Also checked the guard is really live rather than silently compiling out, since a The One thing worth flagging separately: |
nimony is gaining
(comesfrom SYM S*)in nim-lang/nimony#2240 - a transparent wrapper marking statements produced by expandingSYM(a template today), so the debug backend can emit them as a DWARF inlined frame. It opens no scope and carries no semantics of its own.Without this, every native test aborts:
Needs to land with (or before) that PR, since the tag reaches arkham as soon as it does.
The one thing to know
The wrapper's first child is the origin symbol, not a statement. Four passes walk statement children generically, and each has to step over it:
codegen_x64genStmt2/asmStmt,codegen_a64genStmt2- emit the body likestmts. Deliberately noenterScope, unlikeScopeS: the locals an expansion declares belong to the enclosing scope.analyser- its genericanalyseChildrenfallback would analyse the leading symbol as a symbol use, recording a read of the expanded routine at this position.register_allocator- same, and it would carry that phantom read into the live ranges.The two analysis passes are the ones worth a second look. They accept the tag through a permissive
else:without complaint, so a miss there is quiet - it shows up much later as a wrong allocation rather than an assertion. The same shape caused four separate regressions on the nimony side, each found by breakage in a different suite.(pragmax pragmas body)already has this shape, which is why several passes here special-case it too.Testing
arkham builds against the nimony branch that introduces the tag, and no
genStmt2 comesfromassertion remains. I could not run the native suite to completion - it targets Linux ELF and I am on Windows, where it fails earlier onExitProcess. CI on the nimony PR is the real check.