Skip to content

The comment parser reads string and heredoc content as comments where a syntax carries no string state #1664

Open

Description

@ptr727

The prose gate's comment parser does not carry a multi-line string across its lines for several syntaxes, so a line of string content that opens with the language's comment marker is read as a comment. comment-added is the first rule in DEFAULT_RULES that reports every comment it is handed, so it is the first to surface this, and its remedy text is "delete it", which for these lines deletes data the file carries.

Measured against the current gate, each clean before comment-added existed:

input reported
pyproject.toml holding build = """ then a line # Build the artifact before the tests run. line 3
main.tf holding user_data = <<-EOF then # Install the agent before the service starts. line 3
a workflow - run: | block holding cat > f <<EOF then # The template writes this line into the file. line 4
a multi-line double-quoted YAML scalar whose second line opens # ... line 2

The cause is Syntax["carry"]. TOML and HASH, which .tf resolves to, both carry nothing, so a """ or a heredoc body is scanned as code. YAML carries block, and SCRIPT_SCALAR deliberately hands a run: block body to the comment rules because that body is shell, which is right for the shell in it and wrong for a heredoc inside that shell.

A related one with the same reach. An extensionless shell script resolves through syntax_for's fallback to HASH, not SHELL, so .husky/pre-push and .husky/pre-commit model the same language differently: pre-commit is in BY_NAME and gets SHELL with its label and quote carry, while pre-push gets HASH with none.

And one in the block-comment continuation. extracted_comments appends a carried line with leading=True hard-coded, so a line that only closes a block comment and then carries code is reported as a comment line. const x = 1; /* A comment here. / The rest of it. */ const y = 2; reports the second line, whose deletion removes const y = 2; and leaves the comment unterminated. Identical in .json, .jsonc, .css, .xml, .csproj and .html.

comment-wrap and comment-case have the same exposure and rarely reach it, since they fire only when the string content also happens to wrap or to open lowercase.

Why this is filed rather than fixed on #1662. Six consecutive attempts to decide comment identification from the marker's neighbourhood each regressed a language, which is what led to that pull request reporting only a comment whose marker opens its line. Extending carry is parser work of the same kind, and it wants its own change with differential tests against each language's real parser rather than another round on a branch that has had six. The exposure is bounded meanwhile: the finding is visible, the comments label clears it, and no tracked file in this repository currently carries any of these shapes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    gateA rule with no mechanical check, or a check that misses a shapescriptA defect in hub tooling

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions