Parser requests and real-world drift fixtures

[0xLeif]

Request a new language parser or an improvement to an existing one here. Please include the language/version, a minimal public source snippet, the expected exported symbols, the actual SpecSync result, and whether regex or AST mode was used. Adversarial and real-world fixtures are especially useful.

[0xLeif]

A real-world SQLite fixture, and what it cost before it was fixed

This thread asks for adversarial and real-world fixtures. Here is one that came out of adopting 6.0.0-rc.2 on a live repository, filed as #672 and fixed in 6.0.0-rc.4 (#683). It is worth writing up because the useful part is not the bug, it is the shape of the fixture that exposed it.

The pattern

SQLite has no ALTER TABLE ADD COLUMN IF NOT EXISTS. So the only correct way to add a column while keeping both fresh and existing databases right is to write the column twice:

-- schema/001_init.sql
CREATE TABLE events   (id TEXT PRIMARY KEY, url TEXT NOT NULL DEFAULT '');
CREATE TABLE visitors (id TEXT PRIMARY KEY);

-- schema/002_backfill.sql
-- Idempotent back-fill. SQLite has no ADD COLUMN IF NOT EXISTS, so the caller
-- discards the error deliberately: in Go this is literally `_, _ = db.Exec(stmt)`.
ALTER TABLE events ADD COLUMN url TEXT NOT NULL DEFAULT '';

CREATE TABLE carries the column so new databases are correct immediately; the later bare ALTER back-fills older ones. The duplicate is intentional and load-bearing. Remove either half and one of the two database populations is wrong.

What SpecSync did with it, using regex-free .sql files on 6.0.0-rc.2

✗ DB table not found in schema: events      <- created correctly in 001_init.sql
✗ DB table not found in schema: visitors    <- nothing whatsoever to do with the ALTER
✗ ALTER TABLE ADD duplicates existing column `events.url`
  Suggested fixes:
    -> Remove `events` from db_tables or add a CREATE TABLE migration

0 passed, 1 failed

The suggested fix advises adding a CREATE TABLE for a table whose CREATE TABLE is already present and correct.

The fixture-design point, which is the reusable part

visitors is the whole instrument. It has no relationship to the duplicate ALTER at all. It exists in the fixture solely to measure blast radius, and it is what separates two very different diagnoses:

observation	diagnosis
visitors also reported missing	the parse aborted and the result cascaded
only events reported	a single, local, correct error

Without an unrelated table in the file, both defects look like one message about events and you cannot tell a cascade from a legitimate complaint. If you are cutting a parser fixture for this thread, include at least one declaration that the suspect construct cannot possibly affect. It costs one line and it is the difference between a report and a measurement.

Two defects, one cause

1. get_schema_table_names converted a failed schema replay into an empty table set, and the caller read empty as proof of absence. One unparseable migration therefore reported every db_tables entry as missing. The error was not even inspected: Err(_) => return HashSet::new().
2. The AddColumn arm accepted a duplicate only when if_not_exists was set, a branch a SQLite author can never reach, because the dialect has no such syntax.

The first is the recurring shape of this release: a category is empty for want of input, and the code reads it as a verdict.

What shipped in rc.4

• An unreadable schema now degrades to unknown rather than absent, and reports only its own parse error.
• An ADD COLUMN that agrees with the existing column is a no-op. One that contradicts it still fails, and now names both types.

Preserved and pinned by test: a genuinely missing table still errors, a TEXT then INTEGER redeclaration is still fatal, and an ALTER on a table that does not exist reports only that.

Still open on #672, and this is the better fixture request

The same schema written as embedded DDL rather than .sql files still fails:

Supported DDL starts before the previous statement terminates

(src/schema.rs:561.) It is triggered by statements written as single-statement string literals without trailing semicolons, which is entirely valid for db.Exec and is how most Go and TypeScript projects embed their schema. That half of #672 is unfixed.

If you embed DDL in application code, this thread is the right place for a minimal snippet. The useful ones are:

• statements as separate string constants with no terminators
• a slice or array of statements executed in a loop
• dialect idioms whose only correct form looks like a contradiction to a parser, the way the idempotent ADD COLUMN back-fill does

Please include the language and version, the exact db_tables frontmatter, and whether schema_dir is set, since that last one selects an entirely different code path (see #684, fixed in rc.5).