fix: highlight type, enum, func, import and internal keywords - #6207
Merged
Conversation
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.
The book's and website's highlight.js keyword lists have drifted from the lexer:
type,enum,func,importandinternalare all keywords in the lexer'skeywordparser but render as plain identifiers.typeappears 9 times andenum3 times in the book's reference examples, so the gap is visible on pages the docs already ship. This adds the five missing keywords to both copies and notes the lexer as the source of truth.The two files must stay identical below their headers — each says so in a comment — so both get the same edit; I verified the bodies are still byte-identical afterwards, and both parse under
node --check.Scope, and the drift left behind
inandasare already in these lists but are not lexer keywords — both arestdfunctions, declared instd.prql. I left them rather than widen a keyword-sync change into a behavioural one — worth a look separately.The playground's Monaco tokenizer (
web/playground/src/workbench/prql-syntax.js) carries a third copy of the list, drifted further still (letandprqlonly). It uses a different tokenizer format, so syncing it is a separate change rather than the same edit applied a third time.The book's own keyword reference page omits
enumandimportfrom its list. Same drift, also left for a separate change.The other grammars under
grammars/have the same class of drift, in varying amounts. I deliberately did not touch them here: each uses a different format, none can be exercised locally, and a sweep across all of them is much harder to review than this one. #2052 (tests for syntax grammars) is the durable fix — until then a mechanical sweep risks silently breaking a grammar nobody would notice.No regression test: there is no harness for the highlighters, which is what #2052 tracks. Verification here is
node --checkon both files plus the byte-identical body diff.