Skip to content

fix: skip scoped open … in lines when collecting context opens#279

Merged
kim-em merged 2 commits into
mainfrom
issue-277
May 19, 2026
Merged

fix: skip scoped open … in lines when collecting context opens#279
kim-em merged 2 commits into
mainfrom
issue-277

Conversation

@kim-em
Copy link
Copy Markdown
Collaborator

@kim-em kim-em commented May 19, 2026

This PR fixes the extractor so that open … in lines inside earlier definition bodies are no longer hoisted into the generated Challenge.lean / Submission.lean as dangling open … in lines.

extractContextOpens previously matched any line starting with open , so an indented open Classical in inside a def body (as in PR #273's Sturm problem) leaked out and produced parse errors like Missing name after 'end'.

Two heuristics now classify a line as scoped and skip it:

  • Same-line: the stripped line starts with open and an in token appears after the keyword. -- line comments are stripped first so that comments containing the word "in" don't cause false positives.
  • Multi-line: after a candidate top-level open line, we peek past blank and comment-only lines; if the next syntactic line is in or starts with in , we treat the whole thing as scoped.

Regression tests in tests/lean/EvalToolsTests/GenerateTest.lean cover the original Sturm-style reproduction, the multi-line in form, and the comment-with-in false-positive case.

Closes #277.

🤖 Prepared with Claude Code

kim-em and others added 2 commits May 19, 2026 12:54
The extractor's `extractContextOpens` naively matched any line beginning
with `open ` while scanning toward the target theorem, so an `open Classical in`
inside an earlier `def` body was hoisted into the generated `Challenge.lean`
and `Submission.lean` as a dangling `open Classical in`. That is a parse
error which cascaded into confusing `Missing name after 'end'` failures.

Recognize the scoped form by looking for an `in` token after the `open`
keyword (ignoring trailing `--` line comments), and also peek past blank
and comment-only lines to catch the multi-line variant where `in` sits on
its own line.

Closes #277.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`isScopedOpenLine` tokenized the raw stripped line, so a top-level
`open Foo /- mentions in here -/` was misclassified as scoped (the `in`
token landed inside the block comment) and silently dropped.

Strip nested-balanced single-line `/- … -/` blocks before line comments,
then tokenize. Multi-line block comments straddling an `open` command are
still a gap; deferring those until something hits the case in practice.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@kim-em kim-em merged commit 2434b5c into main May 19, 2026
1 check passed
@kim-em kim-em deleted the issue-277 branch May 19, 2026 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Extractor mis-handles open … in inside definitions, emitting dangling open lines in generated files

1 participant