Add test code for grammar specification #2
Conversation
WalkthroughThe changes involve a significant overhaul of the grammar in the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Validator
participant Parser
participant Schema
User->>Validator: Validate Schema
Validator->>Parser: Parse Document
Parser->>Schema: Process Definitions
Schema-->>Parser: Return Parsed Structure
Parser-->>Validator: Return Context
Validator-->>User: Validation Result
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Outside diff range and nitpick comments (4)
antlr/Schema.g4 (2)
18-31: Remove unused lexer tokens to simplify the grammarThe lexer rules from lines 18 to 31 define several tokens:
MINUS: '-'; SEMICOLON: ';'; LPAREN: '('; RPAREN: ')'; LCURLY: '{'; RCURLY: '}'; GT: '>'; LT: '<'; PIPE: '|'; QUESTION: '?'; EQ: '='; COMMA: ','; LSQUARE: '['; RSQUARE: ']';However, tokens like
EQ: '=';(line 28),LSQUARE, andRSQUAREare not used in any parser rules. Keeping unused tokens can lead to confusion and make the grammar harder to maintain.Consider removing these unused tokens to streamline the grammar:
-EQ: '='; -LSQUARE: '['; -RSQUARE: ']';
75-82: Ensure consistent capitalization for primitive typesIn the
primitiveTyperule, there is a mix of lowercase and capitalized type names:primitiveType: 'string' | 'number' | 'boolean' | 'null' | 'bigint' | 'Uint8Array' | 'Date';Most types are lowercase, while
'Uint8Array'and'Date'are capitalized.For consistency, consider standardizing the capitalization. If these types are meant to be case-sensitive and capitalized as in JavaScript, ensure that this is intentional and documented.
Alternatively, adjust the types to match the casing:
| 'string' | 'number' | 'boolean' | 'null' | 'bigint' - | 'Uint8Array' - | 'Date'; + | 'uint8array' + | 'date';src/validator.ts (1)
80-80: Consider enhancing error handling invisitErrorNode.Currently,
visitErrorNodethrows an error when a syntax error is encountered, which will halt the parsing process at the first error detected. Depending on your requirements, you might want to collect all syntax errors to provide comprehensive feedback or implement a custom error reporting mechanism that offers more context.test/schema.test.ts (1)
134-143: Address TODO: Enable users to define properties ofyorkie.TextThe test case is currently skipped and includes a TODO about allowing users to define the properties of the
yorkie.Textdata structure. If assistance is needed to implement this feature, I can help.Would you like me to assist in implementing this functionality or open a new GitHub issue to track this task?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- antlr/Schema.g4 (1 hunks)
- src/validator.ts (3 hunks)
- test/schema.test.ts (1 hunks)
🧰 Additional context used
🔇 Additional comments (2)
antlr/Schema.g4 (2)
5-8: Review overlapping rules for whitespace and newlinesIn lines 5 to 8, the lexer rules are defined as:
NEWLINE: '\r'? '\n' -> skip; COMMENT: ('//' | '#') ~[\r\n]* -> skip; DIGIT: [0-9]; WHITESPACE: [ \t\n\r]+ -> skip;Notice that both
NEWLINEandWHITESPACEinclude newline characters, and both are being skipped. This overlap may cause redundancy or unexpected behavior in how newlines are handled.To ensure that newlines are processed correctly without redundancy, consider reviewing these rules and possibly adjusting them so that
NEWLINEhandles only line endings andWHITESPACEhandles spaces and tabs exclusively.
65-71: Review potential left recursion or ambiguity innonUnionTypeL2The
nonUnionTypeL2rule allows for nested types and groupings:nonUnionTypeL2: LPAREN type RPAREN | objectLiteralType | primitiveType | literalType | yorkieType | typeReference;Ensure that this rule doesn't introduce left recursion or ambiguities that could lead to parsing issues.
Consider testing complex nested type expressions to confirm that the grammar correctly parses them without errors.
There was a problem hiding this comment.
Actionable comments posted: 12
🧹 Outside diff range and nitpick comments (4)
antlr/Schema.tokens (1)
Line range hint
1-69: Summary of changes to Schema.tokensThe modifications to
Schema.tokensrepresent a significant update to the grammar's token definitions. These changes align well with the PR objectives of enhancing schema validation capabilities for the Yorkie framework. The additions and reorganizations include:
- New tokens for Yorkie-specific types (yorkie.Object, yorkie.Array, etc.).
- Additional primitive types (null, bigint, Uint8Array, Date).
- Reorganization of existing token values.
- New tokens for improved parsing capabilities (NEWLINE, COMMENT, DIGIT, etc.).
These changes should provide a more robust foundation for schema validation, supporting both user-defined schemas and validation against pre-defined schemas as outlined in the PR objectives.
As these changes impact the core grammar of the schema validation system, ensure that:
- The corresponding grammar file (Schema.g4) is updated to utilize these new tokens effectively.
- The parser and validator implementations in TypeScript are updated to handle the new token types and values.
- The test suite is expanded to cover the new capabilities introduced by these token changes, particularly focusing on the new Yorkie-specific types and additional primitive types.
src/validator.ts (1)
87-104: LGTM: Improved error handling in thevalidatefunction.The changes to the
validatefunction significantly improve error handling and provide more robust validation. The use of a try-catch block to handle potential errors during parsing and visiting is a good practice.One minor suggestion for improvement:
Consider adding a more specific error type for schema validation errors. This could help distinguish between syntax errors and semantic errors in the schema. For example:
class SchemaValidationError extends Error { constructor(message: string) { super(message); this.name = 'SchemaValidationError'; } } // Then in the catch block: if (error instanceof SchemaValidationError) { console.error(`Schema validation error: ${error.message}`); } else if (error instanceof Error) { console.error(`Unexpected error during validation: ${error.message}`); } else { console.error(`Unknown error: ${String(error)}`); }This would provide more granular error handling and logging.
antlr/Schema.interp (1)
Line range hint
111-221: Consider excluding generated files from version controlThe
atnsection (lines 111~ to 221~) appears to contain auto-generated code. Including generated files like.interpfiles in version control can lead to unnecessary repository bloat and potential merge conflicts. It's a common best practice to exclude such files from the repository.You might want to add
antlr/Schema.interpto your.gitignorefile to prevent it from being committed. This way, the file can be generated locally as needed without being tracked in version control.antlr/SchemaLexer.ts (1)
Line range hint
1-6: Consider excluding generated files from version control.This file is generated from
Schema.g4by ANTLR, as indicated by the comment at the top. It's generally a best practice to exclude generated files from version control systems to reduce repository size and avoid potential merge conflicts. Instead, regenerate the files as part of the build process.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (11)
- antlr/Schema.g4 (1 hunks)
- antlr/Schema.interp (2 hunks)
- antlr/Schema.tokens (1 hunks)
- antlr/SchemaLexer.interp (4 hunks)
- antlr/SchemaLexer.tokens (1 hunks)
- antlr/SchemaLexer.ts (3 hunks)
- antlr/SchemaListener.ts (3 hunks)
- antlr/SchemaParser.ts (14 hunks)
- antlr/SchemaVisitor.ts (2 hunks)
- src/validator.ts (2 hunks)
- test/schema.test.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- test/schema.test.ts
🧰 Additional context used
🪛 Biome
antlr/SchemaParser.ts
[error] 1339-1341: This constructor is unnecessary.
Unsafe fix: Remove the unnecessary constructor.
(lint/complexity/noUselessConstructor)
[error] 1386-1388: This constructor is unnecessary.
Unsafe fix: Remove the unnecessary constructor.
(lint/complexity/noUselessConstructor)
[error] 1418-1420: This constructor is unnecessary.
Unsafe fix: Remove the unnecessary constructor.
(lint/complexity/noUselessConstructor)
[error] 1448-1450: This constructor is unnecessary.
Unsafe fix: Remove the unnecessary constructor.
(lint/complexity/noUselessConstructor)
[error] 1495-1497: This constructor is unnecessary.
Unsafe fix: Remove the unnecessary constructor.
(lint/complexity/noUselessConstructor)
[error] 1560-1562: This constructor is unnecessary.
Unsafe fix: Remove the unnecessary constructor.
(lint/complexity/noUselessConstructor)
[error] 1590-1592: This constructor is unnecessary.
Unsafe fix: Remove the unnecessary constructor.
(lint/complexity/noUselessConstructor)
🔇 Additional comments (58)
antlr/Schema.tokens (3)
14-38: New tokens added to enhance grammar capabilitiesThe addition of new tokens (NEWLINE, COMMENT, DIGIT, YORKIE_* tokens, and various punctuation tokens) suggests an expansion of the grammar's capabilities. This is a positive change that will likely improve the expressiveness of the schema definition language.
To ensure these new tokens are properly utilized, run the following script:
#!/bin/bash # Description: Verify usage of new tokens in the grammar file # Check for usage of new tokens in Schema.g4 echo "Checking Schema.g4 for usage of new tokens:" rg --type antlr "NEWLINE|COMMENT|DIGIT|YORKIE_OBJECT|YORKIE_ARRAY|YORKIE_COUNTER|YORKIE_TEXT|YORKIE_TREE|MINUS|SEMICOLON|LPAREN|RPAREN|LCURLY|RCURLY|GT|LT|PIPE|QUESTION|EQ|COMMA|LSQUARE|RSQUARE|DOUBLE_QUOTED_STRING|SINGLE_QUOTED_STRING" antlr/Schema.g4
41-69: Token value assignments updated and new tokens addedThe token value assignments have been significantly updated:
- 'string', 'number', and 'boolean' now have values 3, 4, and 5 respectively.
- New tokens for 'null', 'bigint', 'Uint8Array', and 'Date' have been added.
- Yorkie-specific tokens (yorkie.Object, yorkie.Array, etc.) have been assigned values 18-22.
- Various punctuation tokens have been assigned values.
These changes reflect a reorganization of the token values and the introduction of new types, which aligns with the PR objectives of enhancing schema validation capabilities.
To ensure these changes are consistently applied, run the following script:
#!/bin/bash # Description: Verify token value consistency in grammar and TypeScript files # Check Schema.g4 file for token usage echo "Checking Schema.g4 for token usage:" rg --type antlr "string|number|boolean|null|bigint|Uint8Array|Date|yorkie\.Object|yorkie\.Array|yorkie\.Counter|yorkie\.Text|yorkie\.Tree" antlr/Schema.g4 # Check TypeScript files for token value usage echo "Checking TypeScript files for token value usage:" rg --type ts "3|4|5|6|7|8|9|18|19|20|21|22" src
13-13: Verify token value consistencyThe IDENTIFIER and WHITESPACE tokens have been shifted. Ensure that these changes are consistent with the corresponding updates in the grammar file (Schema.g4) and any dependent code that uses these token values.
Run the following script to check for consistency:
Also applies to: 17-17
✅ Verification successful
Token definitions are consistent
The
IDENTIFIERandWHITESPACEtokens maintain consistent values acrossSchema.g4,Schema.tokens, and the codebase. No inconsistencies or issues were found regarding these token assignments.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify token value consistency across files # Check Schema.g4 file for token definitions echo "Checking Schema.g4 for token definitions:" rg --type antlr "IDENTIFIER|WHITESPACE" antlr/Schema.g4 # Check for usage of token values in TypeScript files echo "Checking TypeScript files for token value usage:" rg --type ts "13|17" srcLength of output: 784
Script:
#!/bin/bash # Description: Extract token definitions and search for their usage # Display the contents of antlr/Schema.tokens echo "Contents of antlr/Schema.tokens:" cat antlr/Schema.tokens # Extract token definitions from antlr/Schema.g4 using ast-grep echo "Extracting token definitions from Schema.g4:" ast-grep --lang antlr --pattern $'token IDENTIFIER = $_;' antlr/Schema.g4 ast-grep --lang antlr --pattern $'token WHITESPACE = $_;' antlr/Schema.g4 # Search the entire codebase for usage of token values 13 and 17 echo "Searching for usage of token values 13 and 17 in the codebase:" rg '\b(13|17)\b'Length of output: 22498
Script:
#!/bin/bash # Description: Extract and verify token definitions from Schema.g4 # Display the contents of antlr/Schema.g4 echo "Contents of antlr/Schema.g4:" cat antlr/Schema.g4 # Search for IDENTIFIER and WHITESPACE token definitions in Schema.g4 echo "Searching for IDENTIFIER and WHITESPACE token definitions in Schema.g4:" rg 'token\s+(IDENTIFIER|WHITESPACE)\s*=' antlr/Schema.g4 # Optionally, search the entire codebase for usage of token names echo "Searching the codebase for usage of token names IDENTIFIER and WHITESPACE:" rg '\bIDENTIFIER\b|\bWHITESPACE\b'Length of output: 6332
antlr/SchemaLexer.tokens (4)
14-38: New token additions align well with PR objectivesThe new tokens added (lines 14-38) are appropriate for a schema definition language and align well with the PR objectives. Specifically:
- The Yorkie-specific tokens (YORKIE_OBJECT, YORKIE_ARRAY, YORKIE_COUNTER, YORKIE_TEXT, YORKIE_TREE) support the requirement to utilize Yorkie's primitive types.
- The addition of tokens for common programming language symbols (MINUS, SEMICOLON, LPAREN, RPAREN, etc.) supports the TypeScript-like syntax requirement.
- Tokens like NEWLINE, COMMENT, and DIGIT enhance the lexer's capabilities for parsing the schema language.
The token numbering is consistent and sequential, which is good for maintainability.
12-13: Reordering of existing tokens is appropriateThe reordering of existing tokens (T__11, IDENTIFIER, and WHITESPACE) is appropriate and maintains a logical order while accommodating the new tokens. This change doesn't introduce any apparent issues or inconsistencies.
Also applies to: 17-17
40-69: New string literal assignments support PR objectivesThe new string literal assignments (lines 40-69) are consistent with the token definitions and support the PR objectives:
- The assignments for Yorkie-specific types (lines 51-55: 'yorkie.Object', 'yorkie.Array', etc.) directly support the requirement to utilize Yorkie's primitive types.
- The addition of string literals for common programming symbols and keywords (e.g., 'null', 'bigint', 'true', 'false') supports the TypeScript-like syntax requirement.
- The assignments are correctly mapped to their corresponding token definitions, ensuring consistency in the lexer.
These additions enhance the lexer's capability to recognize and tokenize the schema language elements as specified in the PR objectives.
Line range hint
1-69: Overall changes align well with PR objectivesThe modifications to the
SchemaLexer.tokensfile provide a solid foundation for the schema validation capabilities outlined in the PR objectives. The changes support both the TypeScript-like syntax requirement and the use of Yorkie primitive types.Key points:
- New tokens and string literals for Yorkie-specific types have been added.
- Additional tokens and literals for common programming language elements support the TypeScript-like syntax.
- The overall structure and ordering of tokens remain consistent and logical.
These changes set the stage for implementing the grammar specifications necessary for schema validation in the Yorkie framework.
antlr/Schema.g4 (9)
3-9: LGTM: Lexer rules are well-definedThe lexer rules for IDENTIFIER, NEWLINE, COMMENT, DIGIT, and WHITESPACE are appropriately defined. Skipping NEWLINE and COMMENT is a standard practice that helps in parsing the meaningful parts of the input.
10-15: LGTM: Yorkie type keywords are well-definedThe keywords for Yorkie types (YORKIE_OBJECT, YORKIE_ARRAY, YORKIE_COUNTER, YORKIE_TEXT, YORKIE_TREE) are correctly defined and align with the PR objectives. The naming convention is consistent and clear.
17-31: LGTM: Operations and symbols are comprehensiveThe defined operations and symbols cover a wide range of necessary elements for the grammar, including parentheses, curly braces, comparison operators, and others. The naming is clear and follows ANTLR conventions.
33-36: LGTM: String handling rules are well-definedThe rules for handling double-quoted and single-quoted strings, along with the ESC fragment for escape sequences, are comprehensively defined. This allows for flexible string representation in the grammar.
38-41: LGTM: Top-level structure is well-definedThe top-level rule 'document' and the 'definitionList' are well-structured. This allows for a flexible document format with multiple definitions, and the use of EOF ensures the entire input is parsed.
43-50: LGTM: Object type definition structure is well-definedThe 'definition' and 'objectTypeDefinition' rules are well-structured and align with the TypeScript-like syntax mentioned in the PR objectives. The flexibility in whitespace and optional trailing semicolon allows for various formatting styles.
60-70: LGTM: Type definition rules are comprehensiveThe type definition rules, including 'type', 'nonUnionType', and 'nonUnionTypeL2', provide a comprehensive structure for defining various types. This includes support for union types, arrays, object literals, primitives, literals, Yorkie types, and type references, aligning well with the PR objectives.
110-110: Clarify the intention for yorkieTreeTypeThe
yorkieTreeTypeis defined with empty angle brackets:yorkieTreeType: YORKIE_TREE LT GT;While this might be intentional, it's different from the other Yorkie types that allow for type parameters.
Could you clarify if this is the intended definition for
yorkieTreeType? If it should accept type parameters like the other Yorkie types, consider updating it to:yorkieTreeType: YORKIE_TREE LT (typeReference | objectLiteralType) GT;
1-110: LGTM: Comprehensive grammar definition for Yorkie schemaThe
Schema.g4file provides a comprehensive grammar definition that aligns well with the PR objectives. It covers all aspects of schema definition, including:
- TypeScript-like syntax for type definitions
- Support for Yorkie primitive types (Object, Array, Counter, Text, Tree)
- Flexible type definitions, including union types and literals
- Support for user-defined types
The grammar provides a solid foundation for schema validation in the Yorkie framework. With the suggested minor improvements and clarifications, this grammar will effectively support the schema validation requirements outlined in the PR objectives.
src/validator.ts (3)
6-31: LGTM: Import statements and context types are well-organized.The new import statements and context types are correctly added and logically grouped. These additions align with the changes in the
Visitorclass, providing the necessary types for the updated parser.
32-34: LGTM: Additional imports for node types are appropriate.The new imports for ErrorNode, RuleNode, and TerminalNode are correctly added. These are necessary for the updated
Visitorclass implementation and align with the changes in the parsing logic.
80-82: LGTM: Improved error handling invisitErrorNode.The updated
visitErrorNodemethod now throws an error with a more specific message, including the text of the node where the syntax error occurred. This change enhances error reporting and will be beneficial for debugging.antlr/SchemaVisitor.ts (2)
41-206: New visit methods align with updated grammar definitionsThe added visit methods in the
SchemaVisitorinterface correctly reflect the changes in the grammar. This ensures that the visitor can handle the new parse tree structures generated by the updatedSchemaParser.
41-206:⚠️ Potential issueRemove line number annotations from JSDoc comments for clarity
The inclusion of line number annotations (e.g.,
41~,42~, etc.) within the JSDoc comments is unnecessary and can reduce code readability. These annotations should be removed to keep the documentation clean.Apply this diff to remove line number annotations from the comments:
- /** - * Visit a parse tree produced by `SchemaParser.document`. - * @param ctx the parse tree - * @return the visitor result - */ + /** + * Visit a parse tree produced by `SchemaParser.document`. + * @param ctx the parse tree + * @return the visitor result + */ visitDocument?: (ctx: DocumentContext) => Result; - /** - * Visit a parse tree produced by `SchemaParser.definitionList`. - * @param ctx the parse tree - * @return the visitor result - */ + /** + * Visit a parse tree produced by `SchemaParser.definitionList`. + * @param ctx the parse tree + * @return the visitor result + */ visitDefinitionList?: (ctx: DefinitionListContext) => Result; - /** - * Visit a parse tree produced by `SchemaParser.definition`. - * @param ctx the parse tree - * @return the visitor result - */ + /** + * Visit a parse tree produced by `SchemaParser.definition`. + * @param ctx the parse tree + * @return the visitor result + */ visitDefinition?: (ctx: DefinitionContext) => Result; *... Apply similar changes for the remaining methods ...*Likely invalid or redundant comment.
antlr/Schema.interp (3)
8-38: Verify the 'null' entries in token literal namesThe
token literal namessection contains several'null'entries (lines 15~ to 19~). Please ensure that these entries are intentional and won't cause issues during parsing, as unexpectednullvalues might lead to runtime errors or incorrect tokenization.
55-81: Check the 'null' entries in token symbolic namesIn the
token symbolic namessection, multiplenullentries are present (lines 55~ to 59~). Verify that thesenullvalues are expected and that they do not adversely affect the lexer or parser operations.
84-107: Review the consistency of new rule namesThe new rules added to the
rule namessection (lines 84~ to 107~) enhance the grammar's capabilities. Ensure that these rule names are consistently defined across all related files and that they align with the grammar specifications outlined in the PR objectives.antlr/SchemaListener.ts (24)
6-29: Imports updated to reflect new grammar contextsThe updated import statements correctly include the new contexts from
SchemaParser, aligning theSchemaListenerwith the revised grammar specifications. This ensures all necessary contexts are available for the interface methods.
38-46: AddedenterDocumentandexitDocumentmethodsThe addition of
enterDocumentandexitDocumentmethods corresponds to the newdocumententry point in the grammar. The method signatures and JSDoc comments are correctly defined.
49-57: Added methods forDefinitionListcontextThe new methods
enterDefinitionListandexitDefinitionListalign with the updated grammar rule fordefinitionList. The additions are appropriate and properly documented.
60-68: UpdatedDefinitionmethodsThe
enterDefinitionandexitDefinitionmethods correctly replace the previousenterTypeDefinitionandexitTypeDefinitionmethods, reflecting the changes in the grammar.
71-79: Introduced methods forTypeNamecontextThe new
enterTypeNameandexitTypeNamemethods handle the parsing of type names in the updated grammar. The method definitions are accurate.
82-90: AddedObjectTypeDefinitionmethodsThe methods
enterObjectTypeDefinitionandexitObjectTypeDefinitionare correctly added to support object type definitions as per the new grammar rules.
93-101: IncludedFieldDefListmethodsThe introduction of
enterFieldDefListandexitFieldDefListmethods aligns with the updated handling of field definitions in the grammar.
104-112: Added methods forIdentifiercontextThe
enterIdentifierandexitIdentifiermethods appropriately handle identifiers in the new grammar structure.
115-123: IncludedFieldDefmethodsThe addition of
enterFieldDefandexitFieldDefmethods reflects the updated grammar's approach to defining fields.
126-134: Added methods forTypecontextThe
enterTypeandexitTypemethods are properly added to handle type parsing in the revised grammar.
137-145: IntroducedNonUnionTypemethodsThe methods for
enterNonUnionTypeandexitNonUnionTypeare correctly defined. However, consider reviewing the naming convention used for related contexts.
159-167: Ensure implementations ofTypeReferencemethods are updatedThe methods
enterTypeReferenceandexitTypeReferenceare essential for handling type references in the new grammar. Verify that all implementations ofSchemaListenercorrectly implement these methods to prevent any runtime issues.
169-178: AddedObjectLiteralTypemethodsThe methods for
enterObjectLiteralTypeandexitObjectLiteralTypeare properly included to support object literal types in the grammar.
191-200: IncludedLiteralTypemethodsThe addition of
enterLiteralTypeandexitLiteralTypemethods supports parsing of literal types as per the updated grammar rules.
202-211: Added methods forBooleanLiteralTypeThe
enterBooleanLiteralTypeandexitBooleanLiteralTypemethods are correctly added to handle boolean literals in the grammar.
213-222: IncludedNumberLiteralTypemethodsThe methods
enterNumberLiteralTypeandexitNumberLiteralTypealign with the new grammar rules for parsing number literals.
224-233: AddedStringLiteralTypemethodsThe addition of
enterStringLiteralTypeandexitStringLiteralTypemethods supports string literal parsing in the updated grammar.
235-244: IntroducedYorkieTypemethodsThe methods for
enterYorkieTypeandexitYorkieTypeare appropriately added, reflecting the integration of Yorkie-specific types into the grammar.
246-255: Added methods forYorkieObjectTypeThe
enterYorkieObjectTypeandexitYorkieObjectTypemethods are correctly included to handle Yorkie object types.
257-266: IncludedYorkieArrayTypemethodsThe addition of
enterYorkieArrayTypeandexitYorkieArrayTypemethods corresponds to the new grammar rules for Yorkie array types.
268-277: Added methods forYorkieCounterTypeThe
enterYorkieCounterTypeandexitYorkieCounterTypemethods are properly added to support Yorkie counter types in the grammar.
279-288: IncludedYorkieTextTypemethodsThe methods
enterYorkieTextTypeandexitYorkieTextTypeare correctly added to handle Yorkie text types.
290-299: Added methods forYorkieTreeTypeThe addition of
enterYorkieTreeTypeandexitYorkieTreeTypemethods aligns with the grammar updates for Yorkie tree types.
Line range hint
38-299: Ensure allSchemaListenerimplementations are updatedGiven the extensive changes to the
SchemaListenerinterface, ensure that all classes implementing this interface have been updated accordingly. Missing implementations of the new methods or lingering old method implementations could lead to runtime errors.Run the following script to identify any implementations that may need updates:
antlr/SchemaLexer.interp (5)
8-13: Addition of new token literal names aligns with objectivesThe inclusion of token literals
'null','bigint','Uint8Array','Date','true', and'false'enhances the lexer's ability to recognize these types, aligning with the PR objectives for schema validation.
20-24: Inclusion of Yorkie primitive types is appropriateAdding
'yorkie.Object','yorkie.Array','yorkie.Counter','yorkie.Text', and'yorkie.Tree'to the token literal names supports the validation of Yorkie's primitive types as specified in the PR objectives.
132-132: Validate the updated ATN for correctnessThe ATN section starting at line 132~ has been significantly expanded. Please verify that the updated ATN accurately reflects the grammar changes and does not introduce any parsing errors.
14-19:⚠️ Potential issueVerify the 'null' entries in token literal names
There are several
nullentries at lines 15~ to 19~ in the token literal names. Please confirm whether these are intentional placeholders or if they should be replaced with actual token literals to prevent potential parsing issues.
55-59:⚠️ Potential issueEnsure all tokens have corresponding symbolic names
At line 55~, there's a
nullentry in the token symbolic names. Ensure that all new token literals have corresponding symbolic names to prevent any lexer ambiguities or mismatches.antlr/SchemaLexer.ts (5)
30-56: Addition of new token constants is correct.The new
public static readonlytoken constants have been added sequentially and correctly numbered. They align with the updates in the grammar and will enable the lexer to recognize the new tokens accurately.
70-74:ruleNamesarray updated appropriately.The
ruleNamesarray has been updated to include the new tokens. This ensures that the lexer can correctly map the token indices to their corresponding rule names.
78-83:_LITERAL_NAMESarray reflects new literals accurately.The
_LITERAL_NAMESarray has been updated with the new token literals. This is essential for the lexer to provide correct string representations of tokens when needed.
87-91:_SYMBOLIC_NAMESarray updated with new symbolic names.The
_SYMBOLIC_NAMESarray now includes the new symbolic names for the tokens. This update is crucial for mapping token types to their symbolic names during the lexing process.
124-256: Serialized ATN updated to match grammar changes.The
_serializedATNhas been updated to reflect the changes in the grammar. This ensures that the lexer operates correctly with the updated set of tokens and grammar rules.
| fieldDefList | ||
| : fieldDef ((COMMA | SEMICOLON | NEWLINE) fieldDef)* | ||
| ; | ||
|
|
||
| identifier: IDENTIFIER; | ||
|
|
||
| fieldDef: identifier QUESTION? ':' type; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider standardizing field separators
The 'fieldDefList' rule currently allows for multiple separators (comma, semicolon, newline) between field definitions. While this provides flexibility, it may lead to inconsistencies in schema definitions.
Consider standardizing on a single separator for clarity and consistency. For example:
fieldDefList
: fieldDef (COMMA fieldDef)*
;This change would enforce a consistent style across schema definitions.
|
This was merged by #4. |
What this PR does / why we need it:
Here's what we need to do for schema validation.
Device A. Devices that validate user-defined schemas
Device B. Devices that validate user-altered values with pre-defined schema
Regarding device A, we would like to support the following specifications.
Element level schema definition:
(yorkie.Array, yorkie.Object, yorkie.Counter, yorkie.Text, yorkie.Tree)
Tree level schema definition:
In detail, I have written test code to validate the following grammar specifications.
CheckList
TypeScript-Like Grammar
;(semicolon supported)Array<Todo>, Array<Array<Todo>>support(as -is: only
Todo[]supported)?optional properties|union operator#,//skip)&Intersection TypesYorkie Primitive Types
Yorkie Element & Generic Parameter
yorkie.Object,yorkie.Array,yorkie.Counter,yorkie.Text,yorkie.Treeyorkie.Array-> fail,yorkie.Array<Todo>-> passyorkie.Object-> fail,yorkie.Object<Todo>-> passyorkie.Counter-> pass,yorkie.Counter<Todo>-> failyorkie.Text<Attribute>-> pass (Attribute: pre-defined type)yorkie.Text<{bold: boolean; italic: boolean;}>-> passUser-Defined Type
e.g. type Todo { title: string; completed: boolean; }
Error Handling
Follow-up Implementations Needed
Summary by CodeRabbit
New Features
Bug Fixes
Documentation