| Age | Commit message (Collapse) | Author | Lines |
|
|
|
There are three kinds of "byte" literals: byte literals, byte string
literals, and raw byte string literals. None are allowed to have
non-ASCII chars in them.
Two `EscapeError` variants exist for when that constraint is violated.
- `NonAsciiCharInByte`: used for byte literals and byte string literals.
- `NonAsciiCharInByteString`: used for raw byte string literals.
As a result, the messages for raw byte string literals use different
wording, without good reason. Also, byte string literals are incorrectly
described as "byte constants" in some error messages.
This commit eliminates `NonAsciiCharInByteString` so the three cases are
handled similarly, and described correctly. The `mode` is enough to
distinguish them.
Note: Some existing error messages mention "byte constants" and some
mention "byte literals". I went with the latter here, because it's a
more correct name, as used by the Reference.
|
|
Point at all the unnecessary trailing `#`.
Better handle interaction with outer attributes when `;` is missing.
Fix #95030.
|
|
|
|
The modified code to handle parsing raw strings didn't properly account for the case where there was no "#" on either end and erroneously reported this strings as complete. This lead to a panic trying to read off the end of the file.
|
|
|
|
|
|
This diff improves error messages around raw strings in a few ways:
- Catch extra trailing `#` in the parser. This can't be handled in the lexer because we could be in a macro that actually expects another # (see test)
- Refactor & unify error handling in the lexer between ByteStrings and RawByteStrings
- Detect potentially intended terminators (longest sequence of "#*" is suggested)
|
|
|
|
|
|
When refering to or suggesting raw identifiers, refer to them with `r#`.
Fix #65634.
|
|
|
|
|
|
Remove blanket check for existence of other errors before emitting
"type annotation needed" errors, and add some eager checks to avoid
adding obligations when they refer to types that reference
`[type error]` in order to reduce unneded errors.
|
|
When recovering from a parse error inside a block, do not emit type
errors generating on that block's recovered return expression.
Fix #57383.
|
|
|
|
|
|
|
|
|
|
Except those testing parsing during macro expansion
|
|
|