Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

A brace inside an f-string interpolation comment silently changes the resulting value

Closed
#1,252 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c
Domain
compilers

Research direction

Start in src/lexer.c at the interpolation boundary scanner around lines 399 and 422, then read the comment and f-string rules in docs/SPEC.md. Reproduce the issue and compare it with the existing #334/#344 quoted-character cases. Add regression coverage for braces in comments, preserving nested braces and quoted # or braces, and verify the evaluated output is exactly 3\n.

Written by the indexing model from the issue text.

Description

area:runtime-vm bug found-by:code-review kind:silent-wrong

A closing brace inside an f-string interpolation's comment terminates interpolation before the comment ends. The program succeeds but treats the remaining expression as literal text, changing its value.

Reproduce

Save and run this exact two-line program:

print of f"{1 # }
 + 2}"

Actual: exit 0, empty stderr, stdout shown as an escaped string:

"1\n + 2}\n"

Expected: 3\n. The } after # belongs to the comment; the actual expression is 1 + 2.

Paired control: change only the comment text from } to comment:

print of f"{1 # comment
 + 2}"

This exits 0 and prints 3\n. The ordinary parenthesized-expression control also handles the same brace-containing comment correctly:

print of (1 # }
 + 2)

It exits 0 and prints 3\n. This is not a request to introduce multiline expressions: the paired f-string control already accepts and evaluates one.

Cause and contract

The interpolation boundary scanner extracts the expression before recursively tokenizing it. It skips quoted string literals but has no comment state, and counts every exposed {/}. A } in the comment ends extraction; the following newline and + 2} become f-string literal text. The inner tokenizer recognizes the comment only after the boundary was chosen incorrectly.

The lexical contract says comments extend from # to end of line, and f-strings interpolate expressions. Boundary recognition must honor those lexical states.

Regression acceptance

  • The reproducer prints exactly 3\n, matching both controls.
  • Test opening and closing braces within comments, including multiple brace characters.
  • Retain genuine nested-expression brace handling and quoted #/brace characters; # inside a string must not start a comment.
  • Assert exact output after evaluation, not parse success alone: the current defective program exits successfully.

The existing #334/#344 cases cover braces inside quoted strings, not braces inside comments. No matching open or closed report was found.

Verification

Confirmed on a fresh default release build of b91768e23c5a874a64e76e4af9ab291e6aa49983, with inherited EIGS_* variables cleared. Each reproducer and paired control was executed; no runtime or test source was changed. This is a current correctness defect, not a proposed v1 language restriction.

Dominant language
C
Stars
3
Forks
7
Avg merge
3h 56m
Merged PRs (30d)
102

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from InauguralSystems/EigenScript

All issues in InauguralSystems/EigenScript

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.