Extended parsing of preparser options

[anderson4j]

added parsing of preparser options for cypher versions and key=value
Can now parse queries like CYPHER <versionnumber> <option1> = <value1> <option2> = <value2>
where options are identifiers and values either identifiers or numberLiterals

[changeset-bot]

🦋 Changeset detected

Latest commit: 4ff7cf0

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 5 packages

Name	Type
@neo4j-cypher/language-support	Patch
@neo4j-cypher/language-server	Patch
@neo4j-cypher/react-codemirror-playground	Patch
@neo4j-cypher/react-codemirror	Patch
@neo4j-cypher/schema-poller	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[anderson4j]

I guess this should have a changeset but no version bumps?
Edit: added as mentioned above

[ncordon]

It would be cleaner to extract the Cypher part to another rule?

preparserOption:
  EXPLAIN | PROFILE | cypherOptions

cypherOptions:
   CYPHER (cypherVersion | cypherOption)*

[ncordon]

We should add some syntax colouring tests.

Also there's a test in syntacticValidation.test.ts that checks we can use preparser keywords in other parts of the code and it still works, so we should have something for CYPHER there.

There's a rule in CypherCmdParser that overrides the keywords we can use:

// This rule overrides the identifiers adding EXPLAIN, PROFILE, etc
unescapedLabelSymbolicNameString: 
    preparserOption 
    | HISTORY
    | CLEAR
    | PARAM
    | CONNECT
    | DISCONNECT
    | WELCOME
    | SYSINFO
    | unescapedLabelSymbolicNameString_
    ;

Probably best to add a preparserKeyword: EXPLAIN | PROFILE | CYPHER to the preparser so we can rely on that one.

[anderson4j]

Don't think I understand the comment about preparserKeyword. You want preparserKeyword clashing with preparserOption?

[anderson4j]

Here's a comparison query for the new colors
Before:

After:

[anderson4j]

Also in the background the tokentype for the setting name ("runtime" here) was changed, but seems vscode currently has the same color for the new tokentype as the old. Considered removing it, but I suppose the different grouping would have an effect if vscode changes coloring

[ncordon]

Probably assigning enum and enumMember to the key and value would give more contrast difference between the colours.

[anderson4j]

Yup that looks nicer. TODO is still test making (Edit: not todo anymore)