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
- Protected
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(classOf[java.lang.CloneNotSupportedException]) @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: AnyRef): 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): SpecialisedFilterConfig[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]): SpecialisedFilterConfig[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
doubleName
orfloatName
)
- 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
doubleName
orfloatName
)- 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: SpecialisedFilterConfig[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: SpecialisedFilterConfig[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[_ <: AnyRef]
- 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
labelEscapeEnd
for 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
labelGraphicCharacter
andlabelEscapeSequence
within 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 labelSymbolClosingAngle: LabelConfig
How to refer to a
>
symbol in an error message.How to refer to a
>
symbol in an error message.- Since
4.1.0
- Note
defaults to "closing angle bracket"
- def labelSymbolClosingBrace: LabelConfig
How to refer to a
}
symbol in an error message.How to refer to a
}
symbol in an error message.- Since
4.1.0
- Note
defaults to "closing brace"
- def labelSymbolClosingParen: LabelConfig
How to refer to a
)
symbol in an error message.How to refer to a
)
symbol in an error message.- Since
4.1.0
- Note
defaults to "closing parenthesis"
- def labelSymbolClosingSquare: LabelConfig
How to refer to a
]
symbol in an error message.How to refer to a
]
symbol in an error message.- Since
4.1.0
- Note
defaults to "closing square bracket"
- def labelSymbolColon: LabelConfig
How to refer to a
:
symbol in an error message.How to refer to a
:
symbol in an error message.- Since
4.1.0
- Note
defaults to "colon"
- def labelSymbolComma: LabelConfig
How to refer to a
,
symbol in an error message.How to refer to a
,
symbol in an error message.- Since
4.1.0
- Note
defaults to "comma"
- def labelSymbolDot: LabelConfig
How to refer to a
.
symbol in an error message.How to refer to a
.
symbol in an error message.- Since
4.1.0
- Note
defaults to "dot"
- 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"
- def labelSymbolKeyword(symbol: String): LabelConfig
How a given keyword should be described in an error message.
How a given keyword should be described in an error message.
- Since
4.1.0
- Note
defaults to labelling with the symbol itself
- def labelSymbolOpenAngle: LabelConfig
How to refer to a
<
symbol in an error message.How to refer to a
<
symbol in an error message.- Since
4.1.0
- Note
defaults to "open angle bracket"
- def labelSymbolOpenBrace: LabelConfig
How to refer to a
{
symbol in an error message.How to refer to a
{
symbol in an error message.- Since
4.1.0
- Note
defaults to "open brace"
- def labelSymbolOpenParen: LabelConfig
How to refer to a
(
symbol in an error message.How to refer to a
(
symbol in an error message.- Since
4.1.0
- Note
defaults to "open parenthesis"
- def labelSymbolOpenSquare: LabelConfig
How to refer to a
[
symbol in an error message.How to refer to a
[
symbol in an error message.- Since
4.1.0
- Note
defaults to "open square bracket"
- def labelSymbolOperator(symbol: String): LabelConfig
How a given operator should be described in an error message.
How a given operator should be described in an error message.
- Since
4.1.0
- Note
defaults to labelling with the symbol itself
- def labelSymbolSemi: LabelConfig
How to refer to a
;
symbol in an error message.How to refer to a
;
symbol in an error message.- Since
4.1.0
- Note
defaults to "semicolon"
- 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(classOf[java.lang.InterruptedException])
- final def wait(arg0: Long, arg1: Int): Unit
- Definition Classes
- AnyRef
- Annotations
- @throws(classOf[java.lang.InterruptedException])
- final def wait(arg0: Long): Unit
- Definition Classes
- AnyRef
- Annotations
- @throws(classOf[java.lang.InterruptedException]) @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
Parsley
class, as well as theResult
,Success
, andFailure
types. 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.Parsley
contains the bulk of the core "function-style" combinators.parsley.combinator
contains many helpful combinators that simplify some common parser patterns.parsley.character
contains the combinators needed to read characters and strings, as well as combinators to match specific sub-sets of characters.parsley.debug
contains debugging combinators, helpful for identifying faults in parsers.parsley.extension
contains syntactic sugar combinators exposed as implicit classes.parsley.io
contains extension methods to run parsers with input sourced from IO sources.parsley.expr
contains the following sub modules:parsley.expr.chain
contains combinators used in expression parsingparsley.expr.precedence
is a builder for expression parsers built on a precedence table.parsley.expr.infix
contains combinators used in expression parsing, but with more permissive types than their equivalents inchain
.parsley.expr.mixed
contains 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.implicits
contains several implicits to add syntactic sugar to the combinators. These are sub-categorised into the following sub modules:parsley.implicits.character
contains implicits to allow you to use character and string literals as parsers.parsley.implicits.combinator
contains implicits related to combinators, such as the ability to make any parser into aParsley[Unit]
automatically.parsley.implicits.lift
enables postfix application of the lift combinator onto a function (or value).parsley.implicits.zipped
enables 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.zipped
method for building tuples out of several combinators.parsley.errors
contains modules to deal with error messages, their refinement and generation.parsley.errors.combinator
provides combinators that can be used to either produce more detailed errors as well as refine existing errors.parsley.errors.tokenextractors
provides mixins for common token extraction strategies during error message generation: these can be used to avoid implementingunexpectedToken
in theErrorBuilder
.parsley.lift
contains 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.ap
contains functions which allow for the application of a parser returning a function to several parsers returning each of the argument types.parsley.registers
contains combinators that interact with the context-sensitive functionality in the form of registers.parsley.token
contains theLexer
class that provides a host of helpful lexing combinators when provided with the description of a language.parsley.genericbridges
contains 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.