GeezerVison

Related to #2076

Problem

MySQL 8.0 index and column visibility attributes are valid syntax in CREATE TABLE and CREATE INDEX:

CREATE TABLE t1 (
  id bigint NOT NULL,
  secret varchar(10) INVISIBLE,
  KEY idx_id (id) INVISIBLE
);

CREATE INDEX idx_a ON t1 (a) INVISIBLE;

but both fail with ParseException: Encountered unexpected token: "INVISIBLE". #2076 reported the same problem for ALTER TABLE and was fixed in #2234, but that fix covered the ALTER productions only — the CREATE statements parse their options through CreateParameter(), which did not accept the two tokens.

Making an index invisible is the usual first step before dropping it, so table definitions carrying a bare INVISIBLE are common; today the only spelling that gets through the parser is the conditional comment /*!80000 INVISIBLE */, which is skipped as a comment.

Fix

Adds K_VISIBLE and K_INVISIBLE to the CreateParameter() alternation, following the same approach as the other MySQL index/column attributes there. The attributes are collected into the index spec / column specs like any other option and round-trip through the deparser. Both tokens already exist and stay supported in the ALTER productions from #2234, which use separate paths (IndexOption(), AlterExpressionColumnSetVisibility()).

Tests

• testCreateTableIndexVisibility — KEY ... INVISIBLE and UNIQUE KEY ... VISIBLE, asserting the index spec
• testCreateTableColumnVisibility — column-level VISIBLE/INVISIBLE, asserting the column specs
• testCreateTableIndexVisibilityWithOtherIndexOptions — visibility combined with COMMENT and USING BTREE in either order
• testCreateTableQuotedColumnNamedVisible — backtick-quoted columns named visible/invisible still parse as identifiers
• testCreateIndexVisibility — CREATE INDEX ... VISIBLE/INVISIBLE

Full test suite passes (4653 tests, 0 failures). JavaCC parser generation reports the same pre-existing warnings as master with no new choice conflicts.