Interface IParserConfig

interface IParserConfig {
    dynamicTokensEnabled?: boolean;
    errorMessageProvider?: IParserErrorMessageProvider;
    lookaheadStrategy?: ILookaheadStrategy;
    maxLookahead?: number;
    nodeLocationTracking?: nodeLocationTrackingOptions;
    recoveryEnabled?: boolean;
    skipValidations?: boolean;
    traceInitPerf?: number | boolean;
}

Properties

dynamicTokensEnabled?: boolean

Enable This Flag to to support Dynamically defined Tokens. This will disable performance optimizations which cannot work if the whole Token vocabulary is not known During Parser initialization.

See runnable example

errorMessageProvider?: IParserErrorMessageProvider

A custom error message provider. Can be used to override the default error messages. For example:

  • Translating the error messages to a different languages.
  • Changing the formatting.
  • Providing special error messages under certain conditions, e.g: missing semicolons.
lookaheadStrategy?: ILookaheadStrategy

A custom lookahead strategy. Can be used to override the default LL(k) lookahead behavior.

Note that the default lookahead strategy is very well optimized and using a custom lookahead strategy might lead to massively reduced performance.

maxLookahead?: number

Maximum number of tokens the parser will use to choose between alternatives. By default this value is 4. In the future it may be reduced to 3 due to performance considerations.

nodeLocationTracking?: nodeLocationTrackingOptions

Enable computation of CST nodes location. By default this is set to "none", meaning this feature is disabled. See: http://chevrotain.io/docs/guide/concrete_syntax_tree.html#cstnode-location For more details.

recoveryEnabled?: boolean

Is the error recovery / fault tolerance of the Chevrotain Parser enabled.

skipValidations?: boolean

This flag will avoid running the grammar validations during Parser initialization.

This can substantially improve the Parser's initialization (constructor) time.

IParserConfig.traceInitPerf to measure the grammar validations cost for your parser.

Note that the grammar validations are extremely useful during development time, e.g: detecting ambiguities / left recursion. So they should not be skipped during development flows.

  • For example: via a conditional that checks an env variable.
traceInitPerf?: number | boolean

Enabling this flag will print performance tracing logs during parser Initialization (constructor invocation), this is useful to narrow down the cause of the initialization performance problem.

You can also pass a numerical value which affects the verbosity of the traces, this number is the maximum nesting level of the traces, e.g: 0: Traces disabled === 'false' 1: Top Level traces only. 2: One level of nested inner traces. ...

Note that passing the boolean true is identical to passing the numerical value infinity