An ErrorConfig specifies how errors should be produced by the Lexer.

The Lexer is set up to produce a variety of different errors via label-ing, explain-ing, and filter-ing, and some applications of the Verified and Preventative error patterns. The exact content of those errors can be configured here. Errors can be suppressed or specified with different levels of detail, or even switching between vanilla or specialised errors.

A custom ErrorConfig should be created by extending the defaultErrorConfig with record updates to override the relevant default fields. Not configuring something does not mean it will not appear in the message, but will mean it uses the underlying base errors.

This type configures errors that make labels.

A type config is ExplainConfigurable when it is able to configure errors that make labels.

This means config is able to behave like a LabelConfig

This type configures errors that give reasons.

A type config is ExplainConfigurable when it is able to configure an error which provides a reason.

This means config is able to behave like an ExplainConfig

This type configures both errors that make labels and those that make reasons.

A type config is LabelWithExplainConfigurable when it is able to configure an error which provides both a reason and labels.

A type config is NotConfigurable when it is able to specify that no special error should be generated, and instead use default errors.

How a numeric break character should (like _) be referred to or explained within an error.

How unsigned decimal integers (of a possibly given bit-width) should be referred to or explained within an error.

How unsigned hexadecimal integers (of a possibly given bit-width) should be referred to or explained within an error.

How unsigned octal integers (of a possibly given bit-width) should be referred to or explained within an error.

How unsigned binary integers (of a possibly given bit-width) should be referred to or explained within an error.

How generic unsigned integers (of a possibly given bit-width) should be referred to or explained within an error.

How signed decimal integers (of a possibly given bit-width) should be referred to or explained within an error.

How signed hexadecimal integers (of a possibly given bit-width) should be referred to or explained within an error.

How signed octal integers (of a possibly given bit-width) should be referred to or explained within an error.

How signed binary integers (of a possibly given bit-width) should be referred to or explained within an error.

How generic signed integers (of a possibly given bit-width) should be referred to or explained within an error.

How the fact that the end of a decimal integer literal is expected should be referred to within an error.

How the fact that the end of a hexadecimal integer literal is expected should be referred to within an error.

How the fact that the end of an octal integer literal is expected should be referred to within an error.

How the fact that the end of a binary integer literal is expected should be referred to within an error.

How the fact that the end of a generic integer literal is expected should be referred to within an error.

Describes the content of the error when an integer literal is parsed and it is not within the required bit-width.

In filterIntegerOutOfBounds x y r:

• x is the smallest value the integer could have taken,
• y is the largest value the integer could have taken, and
• r is the radix that the integer was parsed using

The bit-width of certain data.

This is used to help enforce parsers of bounded precision to only return types that can losslessly accomodate that precision.

How an identifier should be referred to in an error message.

How a user-defined operator should be referred to in an error message.

How an illegally parsed hard keyword should be referred to as an unexpected component.

How an illegally parsed hard operator should be referred to as an unexpected component.

When parsing identifiers that are required to have specific start characters, how bad identifiers should be reported.

When parsing operators that are required to have specific start/end characters, how bad operators should be reported.

How an ASCII character literal should be referred to or explained in error messages.

How a Latin1 (extended ASCII) character literal should be referred to or explained in error messages.

How a UTF-16 character literal should be referred to or explained in error messages.

How the closing quote of an ASCII character literal should be referred to in error messages.

How the closing quote of a Latin1 (extended ASCII) character literal should be referred to in error messages.

How the closing quote of a UTF-16 character literal should be referred to in error messages.

How an ASCII-only string should literal be referred to or explained in error messages.

With the arguments labelStringAscii multi raw:

• multi: whether this is for a multi-line string
• raw: whether this is for a raw string

How a Latin1-only string should literal be referred to or explained in error messages.

With the arguments labelStringLatin1 multi raw:

• multi: whether this is for a multi-line string
• raw: whether this is for a raw string

How a UTF-16-only string should literal be referred to or explained in error messages.

With the arguments labelStringUnicode multi raw:

• multi: whether this is for a multi-line string
• raw: whether this is for a raw string

How the closing quote(s) of an ASCII string literal should be referred to in error messages.

With the arguments labelStringAsciiEnd multi raw:

• multi: whether this is for a multi-line string
• raw: whether this is for a raw string

How the closing quote(s) of a Latin1 string literal should be referred to in error messages.

With the arguments labelStringLatin1End multi raw:

• multi: whether this is for a multi-line string
• raw: whether this is for a raw string

How the closing quote(s) of a UTF-16 string literal should be referred to in error messages.

With the arguments labelStringUnicodeEnd multi raw:

• multi: whether this is for a multi-line string
• raw: whether this is for a raw string

How general string characters should be referred to in error messages.

How a graphic character (a regular character in the literal) should be referred to or explained in error messages.

How an escape sequence should be referred to or explained in error messages.

How a numeric escape sequence (after the opening character) should be referred to or explained in error messages.

In labelEscapeNumeric radix:

• radix: the radix this specific configuration applies to.

How the end of a numeric escape sequence (after a prefix) should be referred to or explained in error messages.

In labelEscapeNumericEnd prefix radix:

• prefix: the character that started this sequence
• radix: the radix this specific configuration applies to.

How the end of an escape sequence (anything past the opening character) should be referred to or explained within an error message.

How zero-width escape characters should be referred to within error messages.

How string gaps should be referred to within error messages.

How the end of a string gap (the closing slash) should be referred to within error messages.

Configures how filters should be used within the Lexer.

A type config is BasicFilterConfigurable when it is able to provide no error configuration, and instead defer to a regular filter.

Specifies that only filters generating vanilla errors can be used.

A type config is VanillaFilterConfigurable when it is able to generate vanilla errors.

This means config is able to behave like a VanillaFilterConfig

Specifies that only filters generating specialised errors can be used.

A type config is SpecializedFilterConfigurable when it is able to generate specialised errors.

This means config is able to behave like a SpecializedFilterConfig

When a non-ASCII character is found in a ASCII-only character literal, specifies how this should be reported.

When a non-Latin1 character is found in a Latin1-only character literal, specifies how this should be reported.

When a non-ASCII character is found in a ASCII-only string literal, specifies how this should be reported.

When a non-Latin1 character is found in a Latin1-only string literal, specifies how this should be reported.

When a numeric escape sequence requires a specific number of digits but this was not successfully parsed, this describes how to report that error given the number of successfully parsed digits up this point.

In filterEscapeCharRequiresExactDigits radix needed:

• radix: the radix used for this numeric escape sequence.
• needed: the possible numbers of digits required.

When a numeric escape sequence is not legal, this describes how to report that error, given the original illegal character.

In filterEscapeCharNumericSequenceIllegal maxEscape radix:

• maxEscape: the largest legal escape character.
• radix: the radix used for this numeric escape sequence.

Configures what error should be generated when illegal characters in a string or character literal are parsable.

A type config is Unverified when it can disable the verified error for bad characters: this may improve parsing performance slightly on the failure case.

Makes "bad literal chars" generate a bunch of given messages in a specialised error. Requires a map from bad characters to their messages.

Makes "bad literal chars" generate a reason in a vanilla error. Requires a map from bad characters to their reasons.

Character literals parse either graphic characters or escape characters.

String literals parse either graphic characters or escape characters.

Gives names and/or reasons to symbols.

Symbols that do not appear in the map are assumed to be NotConfigurable.

How the required end of a given keyword should be specified in an error.

How the required end of a given operator should be specified in an error.

How the end of a single-line comment should be described or explained.

How the end of a multi-line comment should be described or explained.

The default configuration. This serves as the base configuration, to be customised using record field updates.