class ErrorConfig extends AnyRef
This class is used to specify how errors should be produced by the
Lexer class.
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.
This class should be used by extending it and overriding the relevant parts: all methods here are non-abstract and their default is documented inside. Not configuring something does not mean it will not appear in the message, but will mean it uses the underlying base errors.
- Source
- ErrorConfig.scala
- Since
4.1.0
- Grouped
- Alphabetic
- By Inheritance
- ErrorConfig
- AnyRef
- Any
- Hide All
- Show All
- Public
- All
Instance Constructors
- new ErrorConfig()
Value Members
-
final
def
!=(arg0: Any): Boolean
- Definition Classes
- AnyRef → Any
-
final
def
##(): Int
- Definition Classes
- AnyRef → Any
-
final
def
==(arg0: Any): Boolean
- Definition Classes
- AnyRef → Any
-
final
def
asInstanceOf[T0]: T0
- Definition Classes
- Any
-
def
clone(): AnyRef
- Attributes
- protected[lang]
- Definition Classes
- AnyRef
- Annotations
- @throws( ... ) @native()
-
def
doubleName: String
The name given to doubles.
The name given to doubles.
- Since
4.1.0
- Note
defaults to "IEEE 754 double-precision float"
-
final
def
eq(arg0: AnyRef): Boolean
- Definition Classes
- AnyRef
-
def
equals(arg0: Any): Boolean
- Definition Classes
- AnyRef → Any
-
def
filterCharNonAscii: VanillaFilterConfig[Int]
When a non-ASCII character is found in a ASCII-only character literal, specifies how this should be reported.
When a non-ASCII character is found in a ASCII-only character literal, specifies how this should be reported.
- Since
4.1.0
- Note
defaults to a filter generating the reason "non-ascii character"
-
def
filterCharNonBasicMultilingualPlane: VanillaFilterConfig[Int]
When a non-BMP character is found in a BMP-only character literal, specifies how this should be reported.
When a non-BMP character is found in a BMP-only character literal, specifies how this should be reported.
- Since
4.1.0
- Note
defaults to a filter generating the reason "non-BMP character"
-
def
filterCharNonLatin1: VanillaFilterConfig[Int]
When a non-Latin1 character is found in a Latin1-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.
- Since
4.1.0
- Note
defaults to a filter generating the reason "non-latin1 character"
-
def
filterEscapeCharNumericSequenceIllegal(maxEscape: Int, radix: Int): SpecializedFilterConfig[BigInt]
When a numeric escape sequence is not legal, this describes how to report that error, given the original illegal character.
When a numeric escape sequence is not legal, this describes how to report that error, given the original illegal character.
- maxEscape
the largest legal escape character
- radix
the radix used for this numeric escape sequence
- Since
4.1.0
- Note
defaults to a specialised message stating if the character is larger than the given maximum, or just an illegal codepoint otherwise.
-
def
filterEscapeCharRequiresExactDigits(radix: Int, needed: Seq[Int]): SpecializedFilterConfig[Int]
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.
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.
- radix
the radix used for this numeric escape sequence
- needed
the possible numbers of digits required
- Since
4.1.0
- Note
defaults to a specialised message describing how many digits are required but how many were present.
-
def
filterIntegerOutOfBounds(min: BigInt, max: BigInt, nativeRadix: Int): FilterConfig[BigInt]
This method describes the content of the error when an integer literal is parsed and it is not within the required bit-width.
This method describes the content of the error when an integer literal is parsed and it is not within the required bit-width.
- min
the smallest value the integer could have taken
- max
the largest value the integer could have taken
- nativeRadix
the radix that the integer was parsed using
- Since
4.1.0
- Note
defaults to a specialised error describing what the min and max bounds are.
-
def
filterNameIllFormedIdentifier: FilterConfig[String]
When parsing identifiers that are required to have specific start characters, how bad identifiers should be reported.
When parsing identifiers that are required to have specific start characters, how bad identifiers should be reported.
- Since
4.1.0
- Note
defaults to unexpected "identifier v"
-
def
filterNameIllFormedOperator: FilterConfig[String]
When parsing operators that are required to have specific start/end characters, how bad operators should be reported.
When parsing operators that are required to have specific start/end characters, how bad operators should be reported.
- Since
4.1.0
- Note
defaults to unexpected "operator v"
-
def
filterRealNotExact(name: String): FilterConfig[BigDecimal]
This method describes the content of the error when a real literal is parsed and it is not representable exactly as the required precision.
This method describes the content of the error when a real literal is parsed and it is not representable exactly as the required precision.
- name
the name of the required precision (one of
doubleNameorfloatName)
- Since
4.1.0
- Note
defaults to a specialised error stating that the literal is not exactly representable.
-
def
filterRealOutOfBounds(name: String, min: BigDecimal, max: BigDecimal): FilterConfig[BigDecimal]
This method describes the content of the error when a real literal is parsed and it is not within the bounds perscribed by the required precision.
This method describes the content of the error when a real literal is parsed and it is not within the bounds perscribed by the required precision.
- name
the name of the required precision (one of
doubleNameorfloatName)- min
the smallest value the real could have taken
- max
the largest value the real could have taken
- Since
4.1.0
- Note
defaults to a specialised error describing what the min and max bounds are.
-
def
filterStringNonAscii: SpecializedFilterConfig[StringBuilder]
When a non-ASCII character is found in a ASCII-only string 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.
- Since
4.1.0
- Note
defaults to a filter generating a specialised message of "non-ascii characters in string literal, this is not allowed"
-
def
filterStringNonLatin1: SpecializedFilterConfig[StringBuilder]
When a non-Latin1 character is found in a Latin1-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.
- Since
4.1.0
- Note
defaults to a filter generating a specialised message of "non-latin1 characters in string literal, this is not allowed"
-
def
finalize(): Unit
- Attributes
- protected[lang]
- Definition Classes
- AnyRef
- Annotations
- @throws( classOf[java.lang.Throwable] )
-
def
floatName: String
The name given to floats.
The name given to floats.
- Since
4.1.0
- Note
defaults to "IEEE 754 single-precision float"
-
final
def
getClass(): Class[_]
- Definition Classes
- AnyRef → Any
- Annotations
- @native()
-
def
hashCode(): Int
- Definition Classes
- AnyRef → Any
- Annotations
- @native()
-
final
def
isInstanceOf[T0]: Boolean
- Definition Classes
- Any
-
def
labelCharAscii: LabelWithExplainConfig
How a ASCII character literal should be referred to or explained in error messages.
How a ASCII character literal should be referred to or explained in error messages.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelCharAsciiEnd: LabelConfig
How the closing quote of an ASCII character literal should be referred to in error messages.
How the closing quote of an ASCII character literal should be referred to in error messages.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelCharBasicMultilingualPlane: LabelWithExplainConfig
How a BMP (Basic Multilingual Plane) character literal should be referred to or explained in error messages.
How a BMP (Basic Multilingual Plane) character literal should be referred to or explained in error messages.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelCharBasicMultilingualPlaneEnd: LabelConfig
How the closing quote of a BMP character literal should be referred to in error messages.
How the closing quote of a BMP character literal should be referred to in error messages.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelCharLatin1: LabelWithExplainConfig
How a Latin1 (extended 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.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelCharLatin1End: LabelConfig
How the closing quote of a Latin1 character literal should be referred to in error messages.
How the closing quote of a Latin1 character literal should be referred to in error messages.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelCharUtf16: LabelWithExplainConfig
How a UTF-16 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.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelCharUtf16End: LabelConfig
How the closing quote of a UTF-16 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.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelEscapeEnd: LabelWithExplainConfig
How the end of an escape sequence (anything past the opening character) should be referred to or explained within an error message.
How the end of an escape sequence (anything past the opening character) should be referred to or explained within an error message.
- Since
4.1.0
- Note
defaults to label of "end of escape sequence" with a reason of "invalid escape sequence"
-
def
labelEscapeNumeric(radix: Int): LabelWithExplainConfig
How a numeric escape sequence (after the opening character) 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.
- radix
the radix this specific configuration applies to
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelEscapeNumericEnd(prefix: Char, radix: Int): LabelWithExplainConfig
How the end of a numeric escape sequence (after a prefix) should be referred to or explained in error messages.
How the end of a numeric escape sequence (after a prefix) should be referred to or explained in error messages.
- prefix
the character that started this sequence
- radix
the radix this specific configuration applies to
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelEscapeSequence: LabelWithExplainConfig
How an escape sequence should be referred to or explained in error messages.
How an escape sequence should be referred to or explained in error messages.
- Since
4.1.0
- Note
defaults to label of "escape sequence"
,explains for escape characters do not work in string literals.
- See also
labelEscapeEndfor how to explain what valid escape sequences may be when the lead character has been parsed.
-
def
labelGraphicCharacter: LabelWithExplainConfig
How a graphic character (a regular character in the literal) should be referred to or explained in error messages.
How a graphic character (a regular character in the literal) should be referred to or explained in error messages.
- Since
4.1.0
- Note
defaults to a label of "graphic character"
,explains for graphic characters do not work in string literals.
-
def
labelIntegerBinaryEnd: LabelConfig
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 binary integer literal is expected should be referred to within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerNumberEnd
-
def
labelIntegerDecimalEnd: LabelConfig
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 decimal integer literal is expected should be referred to within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerNumberEnd
-
def
labelIntegerHexadecimalEnd: LabelConfig
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 a hexadecimal integer literal is expected should be referred to within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerNumberEnd
-
def
labelIntegerNumberEnd: LabelConfig
How the fact that the end of a generic 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.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelIntegerOctalEnd: LabelConfig
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 an octal integer literal is expected should be referred to within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerNumberEnd
-
def
labelIntegerSignedBinary(bits: Int): LabelWithExplainConfig
How signed binary integers should of a given bit-width be referred to or explained within an error.
How signed binary integers should of a given bit-width be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerSignedBinary
-
def
labelIntegerSignedBinary: LabelWithExplainConfig
How signed binary integers should be referred to or explained within an error.
How signed binary integers should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerSignedNumber
-
def
labelIntegerSignedDecimal(bits: Int): LabelWithExplainConfig
How signed decimal integers should of a given bit-width be referred to or explained within an error.
How signed decimal integers should of a given bit-width be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerSignedDecimal
-
def
labelIntegerSignedDecimal: LabelWithExplainConfig
How signed decimal integers should be referred to or explained within an error.
How signed decimal integers should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerSignedNumber
-
def
labelIntegerSignedHexadecimal(bits: Int): LabelWithExplainConfig
How signed hexadecimal integers should of a given bit-width be referred to or explained within an error.
How signed hexadecimal integers should of a given bit-width be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerSignedHexadecimal
-
def
labelIntegerSignedHexadecimal: LabelWithExplainConfig
How signed hexadecimal integers should be referred to or explained within an error.
How signed hexadecimal integers should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerSignedNumber
-
def
labelIntegerSignedNumber(bits: Int): LabelWithExplainConfig
How generic signed integers should of a given bit-width be referred to or explained within an error.
How generic signed integers should of a given bit-width be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelIntegerSignedNumber: LabelWithExplainConfig
How generic signed integers should be referred to or explained within an error.
How generic signed integers should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelIntegerSignedOctal(bits: Int): LabelWithExplainConfig
How signed octal integers should of a given bit-width be referred to or explained within an error.
How signed octal integers should of a given bit-width be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerSignedOctal
-
def
labelIntegerSignedOctal: LabelWithExplainConfig
How signed octal integers should be referred to or explained within an error.
How signed octal integers should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerSignedNumber
-
def
labelIntegerUnsignedBinary(bits: Int): LabelWithExplainConfig
How unsigned binary integers should of a given bit-width be referred to or explained within an error.
How unsigned binary integers should of a given bit-width be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerUnsignedNumber
-
def
labelIntegerUnsignedBinary: LabelWithExplainConfig
How unsigned binary integers should be referred to or explained within an error.
How unsigned binary integers should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerUnsignedNumber
-
def
labelIntegerUnsignedDecimal(bits: Int): LabelWithExplainConfig
How unsigned decimal integers should of a given bit-width be referred to or explained within an error.
How unsigned decimal integers should of a given bit-width be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerUnsignedNumber
-
def
labelIntegerUnsignedDecimal: LabelWithExplainConfig
How unsigned decimal integers should be referred to or explained within an error.
How unsigned decimal integers should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerUnsignedNumber
-
def
labelIntegerUnsignedHexadecimal(bits: Int): LabelWithExplainConfig
How unsigned hexadecimal integers should of a given bit-width be referred to or explained within an error.
How unsigned hexadecimal integers should of a given bit-width be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerUnsignedNumber
-
def
labelIntegerUnsignedHexadecimal: LabelWithExplainConfig
How unsigned hexadecimal integers should be referred to or explained within an error.
How unsigned hexadecimal integers should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerUnsignedNumber
-
def
labelIntegerUnsignedNumber(bits: Int): LabelWithExplainConfig
How generic unsigned integers should of a given bit-width be referred to or explained within an error.
How generic unsigned integers should of a given bit-width be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelIntegerUnsignedNumber: LabelWithExplainConfig
How generic unsigned integers should be referred to or explained within an error.
How generic unsigned integers should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelIntegerUnsignedOctal(bits: Int): LabelWithExplainConfig
How unsigned octal integers should of a given bit-width be referred to or explained within an error.
How unsigned octal integers should of a given bit-width be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerUnsignedNumber
-
def
labelIntegerUnsignedOctal: LabelWithExplainConfig
How unsigned octal integers should be referred to or explained within an error.
How unsigned octal integers should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelIntegerUnsignedNumber
-
def
labelNameIdentifier: String
How an identifier should be referred to in an error message.
How an identifier should be referred to in an error message.
- Since
4.1.0
- Note
defaults to "identifier"
-
def
labelNameOperator: String
How a user-defined operator should be referred to in an error message.
How a user-defined operator should be referred to in an error message.
- Since
4.1.0
- Note
defaults to "operator"
-
def
labelNumericBreakChar: LabelWithExplainConfig
How a numeric break character should (like
_) be referred to or explained within an error.How a numeric break character should (like
_) be referred to or explained within an error.- Since
4.1.0
-
def
labelRealBinary: LabelWithExplainConfig
How binary reals should be referred to or explained within an error.
How binary reals should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealNumber
-
def
labelRealBinaryEnd: LabelConfig
How the fact that the end of a binary real literal is expected should be referred to within an error.
How the fact that the end of a binary real literal is expected should be referred to within an error.
- Since
4.1.0
- Note
defaults to
labelRealNumberEnd
-
def
labelRealDecimal: LabelWithExplainConfig
How decimal reals should be referred to or explained within an error.
How decimal reals should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealNumber
-
def
labelRealDecimalEnd: LabelConfig
How the fact that the end of a decimal real literal is expected should be referred to within an error.
How the fact that the end of a decimal real literal is expected should be referred to within an error.
- Since
4.1.0
- Note
defaults to
labelRealNumberEnd
-
def
labelRealDot: LabelWithExplainConfig
How the "dot" that separates the integer and fractional part of a real number should be referred to or explained within an error.
How the "dot" that separates the integer and fractional part of a real number should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelRealDoubleBinary: LabelWithExplainConfig
How binary doubles should be referred to or explained within an error.
How binary doubles should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealBinary
-
def
labelRealDoubleDecimal: LabelWithExplainConfig
How decimal doubles should be referred to or explained within an error.
How decimal doubles should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealDecimal
-
def
labelRealDoubleHexadecimal: LabelWithExplainConfig
How hexadecimal doubles should be referred to or explained within an error.
How hexadecimal doubles should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealHexadecimal
-
def
labelRealDoubleNumber: LabelWithExplainConfig
How generic doubles should be referred to or explained within an error.
How generic doubles should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealNumber
-
def
labelRealDoubleOctal: LabelWithExplainConfig
How octal doubles should be referred to or explained within an error.
How octal doubles should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealOctal
-
def
labelRealExponent: LabelWithExplainConfig
How the trailing exponents of a real number should be referred to or explained within an error.
How the trailing exponents of a real number should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelRealExponentEnd: LabelConfig
How the fact that the end of an exponent part of a real literal is expected should be referred to within an error.
How the fact that the end of an exponent part of a real literal is expected should be referred to within an error.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelRealFloatBinary: LabelWithExplainConfig
How binary floats should be referred to or explained within an error.
How binary floats should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealBinary
-
def
labelRealFloatDecimal: LabelWithExplainConfig
How decimal floats should be referred to or explained within an error.
How decimal floats should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealDecimal
-
def
labelRealFloatHexadecimal: LabelWithExplainConfig
How hexadecimal floats should be referred to or explained within an error.
How hexadecimal floats should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealHexadecimal
-
def
labelRealFloatNumber: LabelWithExplainConfig
How generic floats should be referred to or explained within an error.
How generic floats should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealNumber
-
def
labelRealFloatOctal: LabelWithExplainConfig
How octal floats should be referred to or explained within an error.
How octal floats should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealOctal
-
def
labelRealHexadecimal: LabelWithExplainConfig
How hexadecimal reals should be referred to or explained within an error.
How hexadecimal reals should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealNumber
-
def
labelRealHexadecimalEnd: LabelConfig
How the fact that the end of a hexadecimal real literal is expected should be referred to within an error.
How the fact that the end of a hexadecimal real literal is expected should be referred to within an error.
- Since
4.1.0
- Note
defaults to
labelRealNumberEnd
-
def
labelRealNumber: LabelWithExplainConfig
How generic reals should be referred to or explained within an error.
How generic reals should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelRealNumberEnd: LabelConfig
How the fact that the end of a generic real literal is expected should be referred to within an error.
How the fact that the end of a generic real literal is expected should be referred to within an error.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelRealOctal: LabelWithExplainConfig
How octal reals should be referred to or explained within an error.
How octal reals should be referred to or explained within an error.
- Since
4.1.0
- Note
defaults to
labelRealNumber
-
def
labelRealOctalEnd: LabelConfig
How the fact that the end of an octal real literal is expected should be referred to within an error.
How the fact that the end of an octal real literal is expected should be referred to within an error.
- Since
4.1.0
- Note
defaults to
labelRealNumberEnd
-
def
labelSpaceEndOfLineComment: LabelWithExplainConfig
How the end of a single-line comment should be described or explained.
How the end of a single-line comment should be described or explained.
- Since
4.1.0
- Note
defaults to "end of comment"
-
def
labelSpaceEndOfMultiComment: LabelWithExplainConfig
How the end of a multi-line comment should be described or explained.
How the end of a multi-line comment should be described or explained.
- Since
4.1.0
- Note
defaults to "end of comment"
-
def
labelStringAscii(multi: Boolean, raw: Boolean): LabelWithExplainConfig
How a ASCII-only string literal should be referred to or explained in error messages.
How a ASCII-only string literal should be referred to or explained in error messages.
- multi
whether this is for multi-line strings
- raw
whether this is for raw strings
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelStringAsciiEnd(multi: Boolean, raw: Boolean): LabelConfig
How the closing quote(s) of an ASCII string literal should be referred to in error messages.
How the closing quote(s) of an ASCII string literal should be referred to in error messages.
- multi
whether this is for multi-line strings
- raw
whether this is for raw strings
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelStringCharacter: LabelConfig
How general string characters should be referred to in error messages.
How general string characters should be referred to in error messages.
- Since
4.1.0
- Note
defaults to label of "string character"
,this superscedes
labelGraphicCharacterandlabelEscapeSequencewithin string literals.
-
def
labelStringEscapeEmpty: LabelConfig
How zero-width escape characters should be referred to within error messages.
How zero-width escape characters should be referred to within error messages.
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelStringEscapeGap: LabelConfig
How string gaps should be referred to within error messages.
How string gaps should be referred to within error messages.
- Since
4.1.0
- Note
defaults to label of "string gap"
-
def
labelStringEscapeGapEnd: LabelConfig
How the end of a string gap (the closing slash) should be referred to within error messages.
How the end of a string gap (the closing slash) should be referred to within error messages.
- Since
4.1.0
- Note
defaults to label of "end of string gap"
-
def
labelStringLatin1(multi: Boolean, raw: Boolean): LabelWithExplainConfig
How a Latin1-only string literal should be referred to or explained in error messages.
How a Latin1-only string literal should be referred to or explained in error messages.
- multi
whether this is for multi-line strings
- raw
whether this is for raw strings
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelStringLatin1End(multi: Boolean, raw: Boolean): LabelConfig
How the closing quote(s) of a Latin1 string literal should be referred to in error messages.
How the closing quote(s) of a Latin1 string literal should be referred to in error messages.
- multi
whether this is for multi-line strings
- raw
whether this is for raw strings
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelStringUtf16(multi: Boolean, raw: Boolean): LabelWithExplainConfig
How a UTF-16-only string should literal be referred to or explained in error messages.
How a UTF-16-only string should literal be referred to or explained in error messages.
- multi
whether this is for multi-line strings
- raw
whether this is for raw strings
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelStringUtf16End(multi: Boolean, raw: Boolean): LabelConfig
How the closing quote(s) of a UTF-16 string literal should be referred to in error messages.
How the closing quote(s) of a UTF-16 string literal should be referred to in error messages.
- multi
whether this is for multi-line strings
- raw
whether this is for raw strings
- Since
4.1.0
- Note
defaults to
NotConfigured
-
def
labelSymbol: Map[String, LabelWithExplainConfig]
Gives names and/or reasons to symbols.
Gives names and/or reasons to symbols.
Symbols that do not appear in the map are assumed to be
NotConfigured.- Since
5.0.0
- Note
defaults to the empty map
-
def
labelSymbolEndOfKeyword(symbol: String): String
How the required end of a given keyword should be specified in an error.
How the required end of a given keyword should be specified in an error.
- Since
4.1.0
- Note
defaults to "end of symbol"
-
def
labelSymbolEndOfOperator(symbol: String): String
How the required end of a given operator should be specified in an error.
How the required end of a given operator should be specified in an error.
- Since
4.1.0
- Note
defaults to "end of symbol"
-
final
def
ne(arg0: AnyRef): Boolean
- Definition Classes
- AnyRef
-
final
def
notify(): Unit
- Definition Classes
- AnyRef
- Annotations
- @native()
-
final
def
notifyAll(): Unit
- Definition Classes
- AnyRef
- Annotations
- @native()
-
def
preventRealDoubleDroppedZero: PreventDotIsZeroConfig
Even if leading and trailing zeros can be dropped,
.is not a valid real number: this method specifies how to report that to the user.Even if leading and trailing zeros can be dropped,
.is not a valid real number: this method specifies how to report that to the user.- Since
4.1.0
- Note
defaults to a vanilla explain: "a real number cannot drop both a leading and trailing zero"
-
final
def
synchronized[T0](arg0: ⇒ T0): T0
- Definition Classes
- AnyRef
-
def
toString(): String
- Definition Classes
- AnyRef → Any
-
def
unexpectedNameIllegalIdentifier(v: String): String
How an illegally parsed hard keyword should be referred to as an unexpected component.
How an illegally parsed hard keyword should be referred to as an unexpected component.
- v
the illegal identifier
- Since
4.1.0
- Note
defaults to "keyword v"
-
def
unexpectedNameIllegalOperator(v: String): String
How an illegally parsed hard operator should be referred to as an unexpected component.
How an illegally parsed hard operator should be referred to as an unexpected component.
- Since
4.1.0
- Note
defaults to "reserved operator v"
-
def
verifiedCharBadCharsUsedInLiteral: VerifiedBadChars
Character literals parse either graphic characters or escape characters.
Character literals parse either graphic characters or escape characters. This configuration allows for individual errors when a character not part of either graphic characters or escape characters is encountered.
- Since
4.1.0
- Note
defaults to
Unverified
-
def
verifiedStringBadCharsUsedInLiteral: VerifiedBadChars
String literals parse either graphic characters or escape characters.
String literals parse either graphic characters or escape characters. This configuration allows for individual errors when a character not part of either graphic characters or escape characters is encountered.
- Since
4.1.0
- Note
defaults to
Unverified
-
final
def
wait(): Unit
- Definition Classes
- AnyRef
- Annotations
- @throws( ... )
-
final
def
wait(arg0: Long, arg1: Int): Unit
- Definition Classes
- AnyRef
- Annotations
- @throws( ... )
-
final
def
wait(arg0: Long): Unit
- Definition Classes
- AnyRef
- Annotations
- @throws( ... ) @native()
Name Errors
These control the errors generated with the names component of the Lexer.
Numeric Errors
These control the errors generated with the numeric component of the Lexer.
Space Errors
These control the errors generated with the space component of the Lexer.
Symbol Errors
These control the errors generated with the symbol component of the Lexer.
Text Errors
These control the errors generated with the text component of the Lexer.
This is the documentation for Parsley.
Package structure
The parsley package contains the
Parsleyclass, as well as theResult,Success, andFailuretypes. In addition to these, it also contains the following packages and "modules" (a module is defined as being an object which mocks a package):parsley.Parsleycontains the bulk of the core "function-style" combinators.parsley.combinatorcontains many helpful combinators that simplify some common parser patterns.parsley.charactercontains the combinators needed to read characters and strings, as well as combinators to match specific sub-sets of characters.parsley.debugcontains debugging combinators, helpful for identifying faults in parsers.parsley.exprcontains the following sub modules:parsley.expr.chaincontains combinators used in expression parsingparsley.expr.precedenceis a builder for expression parsers built on a precedence table.parsley.expr.infixcontains combinators used in expression parsing, but with more permissive types than their equivalents inchain.parsley.expr.mixedcontains combinators that can be used for expression parsing, but where different fixities may be mixed on the same level: this is rare in practice.parsley.syntaxcontains several implicits to add syntactic sugar to the combinators. These are sub-categorised into the following sub modules:parsley.syntax.charactercontains implicits to allow you to use character and string literals as parsers.parsley.syntax.liftenables postfix application of the lift combinator onto a function (or value).parsley.syntax.zippedenables boths a reversed form of lift where the function appears on the right and is applied on a tuple (useful when type inference has failed) as well as a.zippedmethod for building tuples out of several combinators.parsley.syntax.extensioncontains syntactic sugar combinators exposed as implicit classes.parsley.errorscontains modules to deal with error messages, their refinement and generation.parsley.errors.combinatorprovides combinators that can be used to either produce more detailed errors as well as refine existing errors.parsley.errors.tokenextractorsprovides mixins for common token extraction strategies during error message generation: these can be used to avoid implementingunexpectedTokenin theErrorBuilder.parsley.liftcontains functions which lift functions that work on regular types to those which now combine the results of parsers returning those same types. these are ubiquitous.parsley.apcontains functions which allow for the application of a parser returning a function to several parsers returning each of the argument types.parsley.statecontains combinators that interact with the context-sensitive functionality in the form of state.parsley.tokencontains theLexerclass that provides a host of helpful lexing combinators when provided with the description of a language.parsley.positioncontains parsers for extracting position information.parsley.genericcontains some basic implementations of the Parser Bridge pattern (see Design Patterns for Parser Combinators in Scala, or the parsley wiki): these can be used before more specialised generic bridge traits can be constructed.