Claude Code transcript

8 prompts · 131 messages · 47 tool calls · 1 commits · 2 pages

#1

Implement the following plan:

Plan: Add source file tracking to parser error messages (Issue #41)

Context

Parser error messages currently show line numbers relative to the preprocessed (expanded) source. When #INCLUDE pulls in a large library like course.module, errors say "line 4335" even though the user's source file is small. This makes errors very hard to diagnose. We need to map expanded line numbers back to original file:line pairs.

Approach

Build a source map in the preprocessor during expansion, then use it in main.go to translate error line numbers before display. This is the least invasive approach — no changes to lexer, parser, or AST.

Changes

1. preproc/preproc.go — Build source map during expansion

  • Add SourceLoc struct: {File string, Line int}
  • Add sourceMap []SourceLoc field to Preprocessor
  • Add SourceMap() []SourceLoc getter method
  • Pass filename through processSource (new parameter) and ProcessFile
  • ProcessSource passes "<input>" as the filename (no file context)
  • For each output line produced, append a SourceLoc{filename, originalLine} entry
  • For #INCLUDE lines: the recursive ProcessFileprocessSource call populates entries for included content; the current line does NOT get an entry
  • For directives that emit blank lines (#DEFINE, #IF, #ELSE, #ENDIF, #COMMENT, etc.): append {filename, lineNum}
  • For skipped lines (inactive condStack): append {filename, lineNum}
  • For regular source lines: append {filename, lineNum}
  • Source map is 0-indexed (entry 0 = expanded line 1)

2. main.go — Translate error line numbers using source map

  • After parsing, if there are errors, get pp.SourceMap()
  • For each error string matching "line NNN: ...", look up NNN in the source map
  • Replace with "filename:line: ..." format (standard compiler error format)
  • If the file is the top-level input file, can show just "filename:line:" or the full path
  • If lookup fails (out of bounds), fall through to original message

3. preproc/preproc_test.go — Test source map

  • Test that ProcessFile with #INCLUDE produces correct source map entries
  • Test that non-included file maps lines 1:1
  • Test that ProcessSource uses "<input>" as filename

Files to modify

  • preproc/preproc.go — add SourceLoc, sourceMap field, pass filename, build map
  • main.go — translate error messages using source map
  • preproc/preproc_test.go — add source map tests

Verification

go test ./...                    # all tests pass
# Manual test with course module:
./occam2go -I kroc/modules/course/libsrc -D TARGET.BITS.PER.WORD=32 -o test.go kroc/modules/course/examples/test_utils.occ
# Error messages should now show filename:line instead of just line NNN

If you need specific details from before exiting plan mode (like exact code snippets, error messages, or content you generated), read the full transcript at: /home/david/.claude/projects/-home-david-projects-code-associates-occam2go/0d8c6c7b-51c0-4085-94aa-867d3704a672.jsonl

9 edit · 8 taskupdate · 5 bash · 4 taskcreate · 3 read · 1 grep

All done. Here's a summary of the changes:

preproc/preproc.go — Added source map tracking: - New SourceLoc struct with File and Line fields - New sourceMap []SourceLoc field on Preprocessor - New SourceMap() getter method - processSource now takes a filename parameter and appends a SourceLoc entry for each output line - ProcessFile passes the original filename; ProcessSource passes "<input>" - For #INCLUDE, the recursive call populates entries for the included content; only adds an entry for the #INCLUDE line itself when the file was already included (dedup case)

main.go — Error translation: - New translateError() function that rewrites "line NNN: msg" to "file:line: msg" using the source map - Parser errors are translated before printing

preproc/preproc_test.go — Three new tests: - TestSourceMapSimple — verifies 1:1 mapping for plain source with <input> filename - TestSourceMapWithDirectives — verifies directives still produce correct line mappings - TestSourceMapWithInclude — verifies included file content maps to the included file's name and lines

#2

Thank you. Please create a PR for this feature.

6 bash
9227d08
Add source file tracking to parser error messages
#3

Can you try the manual test with the example file cited in the original bug report?

4 bash · 3 grep · 1 read

The errors now correctly point to kroc/modules/course/examples/test_utils.occ at lines 19 and 75 — instead of the unhelpful line 4335 / line 4391 from the expanded output. The errors are actually in the user's source file, not the course library, which answers the question from the bug report.

One thing I notice: the errors are printed twice. Let me check why.

Only 12 lines — it's not actually duplicated. The earlier output I saw was an artifact of the tool display appending stderr twice. The actual output is correct:

Parse errors:
  kroc/modules/course/examples/test_utils.occ:19: expected type after VAL, got [
  kroc/modules/course/examples/test_utils.occ:19: unexpected token: INT
  kroc/modules/course/examples/test_utils.occ:19: unexpected token: ]
  kroc/modules/course/examples/test_utils.occ:75: expected ), got STRING
  ...

Before this change, the same errors showed line 4335 and line 4391. Now they correctly point to test_utils.occ lines 19 and 75 — the actual locations in the user's source file.

#4

Ok great. Can you update the task list in the PR description to reflect that you've performed the manual test now?

2 bash
#5

Thank you. I've approved the PR and CI checks have passed. Please merge.

1 bash
#7

/exit exit

#8

Catch you later!

#6

Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.