Skip to content

Let comments never change whether a statement converts (D327) - #134

Merged
kvlonge merged 4 commits into
mainfrom
fix/d327-select-comments
Nov 7, 2026
Merged

kvlonge merged 4 commits into
mainfrom
fix/d327-select-comments

Conversation

@kvlonge

@kvlonge kvlonge commented Nov 6, 2026 •

Copy link
Copy Markdown
Contributor

Launch blocker D327 (from D320): comments must never change whether a statement converts.

The bug

SELECT /* c */ 1 AS v and SELECT -- note\n 1 AS v refused the whole statement with SQ0002, "no rule handles post_select_comments set on node:select". That was 602 of the playground lane's 3,263 generated statements. Snowflake compiles both and returns column V (A's receipts, wip/d320-playground-basics 6111431), so the refusal was ours alone.

The fix

Both changes are in conversion/_helpers/support/tree.rs, which already decides which tree fields are cosmetic:

  1. post_select_comments joins COSMETIC_FIELDS, beside trailing_comments, pre_alias_comments and the others. The comment is dropped from the output, the same as comments everywhere else.

  2. The sweep turned up a second case. A comment straight after an expression wraps it in an annotated node that holds only this and trailing_comments. A rule that needs a literal then sees the wrapper: ROUND(amount, 1 /* c */) refused with SQ0003 while ROUND(amount, 1) converted. When the tree is built, a wrapper that holds nothing but comments is now replaced by the node it wraps.

  3. Round 1 review (auditor record 09453d8) found that unwrapping also renamed unaliased items: SELECT 'x' /* c */ FROM orders took the name 'X'. Main had the same gap, since it named it 'X' too; no receipt records whether Snowflake's name includes the comment. A select item's own wrapper now stays (unwrap_field), and the projection rule refuses it with SQ0009 unless it wraps a column, star or alias, as the column-name rule's conditions already state. SELECT 'x' /* c */ AS v and SELECT amount /* c */ still convert.

Sweep

38 comment positions were converted over a schema (orders, customers). With only change 1, 1 of the first 32 still refused (the comment after ROUND's literal scale); with both changes, 0 of 38 refuse. I didn't run the sweep on unchanged main; the after-SELECT positions are the D320 report's. The positions:

  • after SELECT (block and line), before or after DISTINCT, between select items, after an alias or AS
  • after FROM, after the table, before WHERE (line), after WHERE, inside a comparison
  • after GROUP BY / ORDER BY / LIMIT / HAVING / QUALIFY, after a CTE name, after SELECT inside a CTE and inside a subquery
  • before a CTE's, a subquery's and a function's closing paren, inside function calls, after JOIN and ON, in CASE and in a window
  • after UNION ALL, after the second SELECT of a UNION, trailing at the end (block and line)
  • after literals: a select item, LIMIT, an IN list, a string argument, a comparison, a date part

Tests

test_analyze gains five rows: a block and a line comment after SELECT, comments after SELECT in a CTE and a subquery, a comment after a literal argument, and an unaliased literal carrying a comment (SQ0009, which fails with query.rs reverted to main). With tree.rs reverted to main, the first new row fails; with the fix, all pass.

Gate

D94 gate on exact head 9c008e0 (58731ec + merge of main fc15d51, clean, no conflicts), every .rs touched before the build:

  • make check-merge (check-ci + test-rust): exit 0. fmt, clippy, ruff, ty and fensu clean; 24/24 test binaries passed.
  • sqlquack verify --require-verified --strict-errors --python .venv/bin/python: 12,033 cases, 7,997 passed, 1,035 diverged as expected, 2,964 refused, 37 typed, 0 pending, 0 unproven, 0 failed; 226 of 226 equivalences and rules verified.
  • syntax-coverage results … --against main fc15d51's results-baseline.json: 0 regressions, 0 other changes; no baseline re-record needed.
  • Hygiene scan clean; no agent trailers.

Auditor: approved at 7392627 (record 6a306de), extended to 58731ec (record 976fb43). GitHub Actions is blocked by billing; the local D94 gate counts.

A comment straight after SELECT set post_select_comments, which no rule
read, so the whole statement refused (602 of the playground's 3,263
generated statements). It is now cosmetic like every other comment
field. A comment after an expression wrapped it in an annotated node,
so a rule needing a literal, such as ROUND's scale, saw a wrapper and
refused; a wrapper that holds only comments is now unwrapped. Both are
dropped from the output, as comments elsewhere are.
Unwrapping comment-only wrappers dropped the comment from an unaliased
literal's written text, so SELECT 'x' /* c */ took the name 'X', which no
receipt records. Main had the same gap. The select item's own wrapper now
stays, and the projection rule refuses it with SQ0009 unless it wraps a
column, star or alias, as the column-name rule's conditions state.
kvlonge added a commit that referenced this pull request Nov 6, 2026
No behaviour change: the select-item wrapper rule from the previous commit
now lives in unwrap_field, and the inline comment and long doc comment go.

kvlonge commented Nov 7, 2026

Copy link
Copy Markdown
Contributor Author

D94 gate on exact head 9c008e0 (58731ec + merge of main fc15d51, clean, no conflicts), every .rs touched before the build:

  • make check-merge (check-ci + test-rust): exit 0. fmt, clippy, ruff, ty and fensu clean; 24/24 test binaries passed.
  • sqlquack verify --require-verified --strict-errors --python .venv/bin/python: 12,033 cases, 7,997 passed, 1,035 diverged as expected, 2,964 refused, 37 typed, 0 pending, 0 unproven, 0 failed; 226 of 226 equivalences and rules verified.
  • syntax-coverage results … --against main fc15d51's results-baseline.json: 0 regressions, 0 other changes; no baseline re-record needed.
  • Hygiene scan clean; no agent trailers.

@kvlonge
kvlonge marked this pull request as ready for review November 7, 2026 01:57
@kvlonge
kvlonge merged commit 9c008e0 into main Nov 7, 2026
1 check failed
@kvlonge
kvlonge deleted the fix/d327-select-comments branch November 7, 2026 07:42
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.

1 participant