Repository navigation
Let a comment after a string literal keep it a literal in the type checks - #139
Merged
Merged
Conversation
…ecks (D351) A comment straight after an expression wraps it in an Annotated node. string_literal looked through aliases and parentheses but not that wrapper, so in WHERE ordered_at >= '2026-10-03' -- c the literal no longer counted as a string literal, the run-time coercion exemption for comparisons did not apply, and Snowflake checks reported W210. A comment-only wrapper is now seen through; one asserting a type is not.
kvlonge
added a commit
that referenced
this pull request
Nov 7, 2026
Contributor
Author
|
Gate on exact head 139fc9e (44e662c plus a clean merge of main 1362af4, no conflicts), every .rs touched before the build:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Launch blocker D351 (a D327 follow-up from the playground lane): a comment after a string literal changed the playground's Checks outcome.
The bug
On main 9c008e0, with a schema where ORDERS.ORDERED_AT is TIMESTAMP_NTZ, the playground's
analyzereported W210 "Incompatible comparison between timestamp and string" forselect order_id from orders where ordered_at >= '2026-10-03' -- trailing comment, and for the same query with/* c */. Without the comment, or with a;, checks pass. Snowflake compiles all four, casting the text implicitly. Translation already passed in all four.The cause
A comment straight after an expression wraps it in an
Annotatednode.string_literalinlineage/_helpers/checks/coercion.rslooked through aliases and parentheses but not that wrapper. So'2026-10-03' -- cstopped counting as a string literal, the run-time coercion exemption for Snowflake comparisons didn't apply, and W210 fired. The native CLI looked clean only becausesqlquack checktakes no schema and can't type ORDERED_AT. The typed checks run only where a schema is supplied, as the playground'sanalyze(sql, SCHEMA)does.The fix
string_literalnow looks through anAnnotatednode that only carries comments. A wrapper that asserts a type (type_assertion/type_like) is still not a literal. The same helper also feedsliteral_coercesand the signature checks, so they see through the comment too.Tests
test_checksgains one Snowflake row:shipped_at >= '2026-10-03' /* c */ AND shipped_at < '2026-10-04' -- cexpects no findings. On main it fails with two W210s, at offsets 35 and 74; with the fix it passes./* c */and-- cinserted after every token, 296 variants in all, comparing finding codes with the uncommented query. On main, 10 of 296 differ, all W210 on a date, time, timestamp or number compared with a commented string literal. With the fix, 0 of 296 differ.Gate
GATE_RESULTS
Draft, for the auditor. GitHub Actions is blocked by billing; the local D94 gate counts.