about summary refs log tree commit diff
path: root/compiler/rustc_lexer/src/unescape.rs
AgeCommit message (Collapse)AuthorLines
2025-04-04Replace `rustc_lexer/unescape` with `rustc-literal-escaper` crateGuillaume Gomez-438/+0
2025-03-18Revert "Rollup merge of #136355 - ↵Ralf Jung-0/+438
GuillaumeGomez:proc-macro_add_value_retrieval_methods, r=Amanieu" This reverts commit 08dfbf49e30d917c89e49eb14cb3f1e8b8a1c9ef, reversing changes made to 10bcdad7df0de3cfb95c7bdb7b16908e73cafc09.
2025-02-10Extract `unescape` from `rustc_lexer` into its own crateGuillaume Gomez-438/+0
2024-04-24Improved the compiler code with clippyMichael Scholten-2/+2
2024-01-25Use `unescape_unicode` for raw C string literals.Nicholas Nethercote-19/+14
They can't contain `\x` escapes, which means they can't contain high bytes, which means we can used `unescape_unicode` instead of `unescape_mixed` to unescape them. This avoids unnecessary used of `MixedUnit`.
2024-01-25Rename the unescaping functions.Nicholas Nethercote-4/+8
`unescape_literal` becomes `unescape_unicode`, and `unescape_c_string` becomes `unescape_mixed`. Because rfc3349 will mean that C string literals will no longer be the only mixed utf8 literals.
2024-01-25Rename and invert sense of `Mode` predicates.Nicholas Nethercote-32/+24
I find it easier if they describe what's allowed, rather than what's forbidden. Also, consistent naming makes them easier to understand.
2024-01-25Rework `CStrUnit`.Nicholas Nethercote-34/+45
- Rename it as `MixedUnit`, because it will soon be used in more than just C string literals. - Change the `Byte` variant to `HighByte` and use it only for `\x80`..`\xff` cases. This fixes the old inexactness where ASCII chars could be encoded with either `Byte` or `Char`. - Add useful comments. - Remove `is_ascii`, in favour of `u8::is_ascii`.
2024-01-25Use `from` instead of `into` in unescaping code.Nicholas Nethercote-4/+4
The `T` type in these functions took me some time to understand, and I find the explicit `T` in the use of `from` makes the code easier to read, as does the `u8` annotation in `scan_escape`.
2024-01-12Detect `NulInCStr` error earlier.Nicholas Nethercote-2/+15
By making it an `EscapeError` instead of a `LitError`. This makes it like the other errors produced when checking string literals contents, e.g. for invalid escape sequences or bare CR chars. NOTE: this means these errors are issued earlier, before expansion, which changes behaviour. It will be possible to move the check back to the later point if desired. If that happens, it's likely that all the string literal contents checks will be delayed together. One nice thing about this: the old approach had some code in `report_lit_error` to calculate the span of the nul char from a range. This code used a hardwired `+2` to account for the `c"` at the start of a C string literal, but this should have changed to a `+3` for raw C string literals to account for the `cr"`, which meant that the caret in `cr"` nul error messages was one short of where it should have been. The new approach doesn't need any of this and avoids the off-by-one error.
2023-12-13Rename some unescaping functions.Nicholas Nethercote-9/+7
`unescape_raw_str_or_raw_byte_str` only does checking, no unescaping. And it also now handles C string literals. `unescape_raw_str` is used for all the non-raw strings.
2023-12-13Adjust `Mode::is_unicode_escape_disallowed`.Nicholas Nethercote-2/+3
Some cases are unreachable.
2023-12-09Tweak `Mode`.Nicholas Nethercote-34/+38
- Add `use Mode::*` to avoid all the qualifiers. - Reorder the variants. The existing order makes no particular sense, which has bugged me for some time. I've chosen an order that makes sense to me.
2023-12-09Remove an unnecessary `into`.Nicholas Nethercote-1/+1
2023-12-09Eliminate `is_byte: bool` args in unescaping code.Nicholas Nethercote-21/+19
These don't really make sense since C string literals were added. This commit removes them in favour for `mode: Mode` args. `ascii_check` still has a `characters_should_be_ascii: bool` arg. Also, `characters_should_be_ascii` is renamed to be shorter.
2023-12-09Remove explicit `\n` and `\t` handling in `unescape_str_common`.Nicholas Nethercote-2/+0
The fallback `_` case works for these chars, no need to treat them specially.
2023-12-09Add some useful comments.Nicholas Nethercote-4/+8
2023-12-07Fix an out-of-date comment.Nicholas Nethercote-1/+1
2023-12-07Identify impossible cases in `ascii_escapes_should_be_ascii`.Nicholas Nethercote-2/+3
Raw strings (of all kinds) don't support escapes, so this function should never be called on them.
2023-12-07De-pub some functions.Nicholas Nethercote-3/+3
2023-07-23fix some clippy::style findingsMatthias Krüger-1/+1
comparison_to_empty iter_nth_zero for_kv_map manual_next_back redundant_pattern
2023-05-02refactor unescapeDeadbeef-30/+61
2023-05-02initial step towards implementing C string literalsDeadbeef-78/+121
2023-03-09fix(lexer): not skipped whitespace warning for '\x0c'bohan-3/+3
2023-01-17Remove double spaces after dots in commentsMaybe Waffle-1/+1
2022-12-12minor code cleanupsMatthias Krüger-2/+1
2022-11-08Simplify `unescape_{char,byte}`.Nicholas Nethercote-9/+5
The `usize` isn't needed in the error case.
2022-11-05Rename some `result` variables as `res`, for consistency.Nicholas Nethercote-6/+6
2022-11-05Remove `unescape_byte_literal`.Nicholas Nethercote-14/+2
It's easy to just use `unescape_literal` + `byte_from_char`.
2022-11-04Improve comments.Nicholas Nethercote-4/+1
Remove a low-value comment, remove a duplicate comment, and correct a third comment.
2022-11-04Make non-ASCII errors more consistent.Nicholas Nethercote-5/+2
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.
2022-11-03Use `Mode` less.Nicholas Nethercote-24/+22
It's passed to numerous places where we just need an `is_byte` bool. Passing the bool avoids the need for some assertions. Also rename `is_bytes()` as `is_byte()`, to better match `Mode::Byte`, `Mode::ByteStr`, and `Mode::RawByteStr`.
2022-11-03Clarify range calculations.Nicholas Nethercote-10/+12
There is some subtlety here.
2022-11-03Rename some variables.Nicholas Nethercote-38/+32
These have been bugging me for a while. - `literal_text`: `src` is also used and is shorter and better. - `first_char`: used even when "first" doesn't make sense; `c` is shorter and better. - `curr`: `c` is shorter and better. - `unescaped_char`: `result` is also used and is shorter and better. - `second_char`: these have a single use and can be elided.
2022-09-28Small cleanups in unescaping code.Nicholas Nethercote-14/+11
- Rename `unescape_raw_str_or_raw_byte_str` as `unescape_raw_str_or_byte_str`, which is more accurate. - Remove the unused `Mode::in_single_quotes` method. - Make some assertions more precise, and add a missing one to `unescape_char_or_byte`. - Change all the assertions to `debug_assert!`, because this code is reasonably hot, and the assertions aren't required for memory safety, and any violations are likely to be sufficiently obvious that normal tests will trigger them.
2022-09-27Fix an incorrect comment.Nicholas Nethercote-1/+1
If a `\x` escape occurs in a non-byte literals (e.g. char literal, string literal), it must be <= 0xff.
2022-06-28fix typo in commentProloy Mishra-1/+1
2022-02-24Improve `scan_escape`.Nicholas Nethercote-23/+22
`scan_escape` currently has a fast path (for when the first char isn't '\\') and a slow path. This commit changes `scan_escape` so it only handles the slow path, i.e. the actual escaping code. The fast path is inlined into the two call sites. This change makes the code faster, because there is no function call overhead on the fast path. (`scan_escape` is a big function and doesn't get inlined.) This change also improves readability, because it removes a bunch of mode checks on the the fast paths.
2021-11-06use matches!() macro in more placesMatthias Krüger-5/+4
2021-10-15Revert "Auto merge of #89709 - clemenswasser:apply_clippy_suggestions_2, ↵Matthias Krüger-5/+6
r=petrochenkov" The PR had some unforseen perf regressions that are not as easy to find. Revert the PR for now. This reverts commit 6ae8912a3e7d2c4c775024f58a7ba4b1aedc4073, reversing changes made to 86d6d2b7389fe1b339402c1798edae8b695fc9ef.
2021-10-10Apply clippy suggestionsClemens Wasser-6/+5
2021-08-11Renamed variable str -> tail for clarityAnton Golov-5/+5
2021-08-11Warn when an escaped newline skips multiple linesAnton Golov-0/+9
2021-07-30Add warning when whitespace is not skipped after an escaped newline.Anton Golov-4/+30
2020-12-18Fix typoHirochika Matsumoto-1/+1
2020-08-30mv compiler to compiler/mark-0/+344