rust-lang/rust
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
51b51b51d7931da85280382a81c4dd80c73ca754
rust/tests/ui/rfcs/rfc-3348-c-string-literals/no-nuls.stderr

93 lines
2.0 KiB
Plaintext
Raw Normal View History

reimplement C string literals
2023-07-16 18:59:05 +00:00
error: null characters in C string literals are not supported
Detect `NulInCStr` error earlier. 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-07 09:53:08 +11:00
--> $DIR/no-nuls.rs:14:7
update and add a few tests
2023-03-06 07:10:23 +00:00
|
LL | c"\0";
reimplement C string literals
2023-07-16 18:59:05 +00:00
| ^^
update and add a few tests
2023-03-06 07:10:23 +00:00
reimplement C string literals
2023-07-16 18:59:05 +00:00
error: null characters in C string literals are not supported
Detect `NulInCStr` error earlier. 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-07 09:53:08 +11:00
--> $DIR/no-nuls.rs:15:7
update and add a few tests
2023-03-06 07:10:23 +00:00
|
LL | c"\u{00}";
reimplement C string literals
2023-07-16 18:59:05 +00:00
| ^^^^^^
update and add a few tests
2023-03-06 07:10:23 +00:00
reimplement C string literals
2023-07-16 18:59:05 +00:00
error: null characters in C string literals are not supported
Detect `NulInCStr` error earlier. 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-07 09:53:08 +11:00
--> $DIR/no-nuls.rs:16:7
update and add a few tests
2023-03-06 07:10:23 +00:00
|
Replace ASCII control chars with Unicode Control Pictures ``` error: bare CR not allowed in doc-comment --> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32 | LL | /// doc comment with bare CR: '␍' | ^ ```
2024-07-09 16:46:09 +00:00
LL | c"␀";
reimplement C string literals
2023-07-16 18:59:05 +00:00
| ^
update and add a few tests
2023-03-06 07:10:23 +00:00
reimplement C string literals
2023-07-16 18:59:05 +00:00
error: null characters in C string literals are not supported
Detect `NulInCStr` error earlier. 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-07 09:53:08 +11:00
--> $DIR/no-nuls.rs:17:7
update and add a few tests
2023-03-06 07:10:23 +00:00
|
LL | c"\x00";
reimplement C string literals
2023-07-16 18:59:05 +00:00
| ^^^^
update and add a few tests
2023-03-06 07:10:23 +00:00
reimplement C string literals
2023-07-16 18:59:05 +00:00
error: null characters in C string literals are not supported
Detect `NulInCStr` error earlier. 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-07 09:53:08 +11:00
--> $DIR/no-nuls.rs:18:8
update and add a few tests
2023-03-06 07:10:23 +00:00
|
Replace ASCII control chars with Unicode Control Pictures ``` error: bare CR not allowed in doc-comment --> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32 | LL | /// doc comment with bare CR: '␍' | ^ ```
2024-07-09 16:46:09 +00:00
LL | cr"␀";
Detect `NulInCStr` error earlier. 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-07 09:53:08 +11:00
| ^
error: null characters in C string literals are not supported
--> $DIR/no-nuls.rs:28:7
|
LL | c"\0";
| ^^
error: null characters in C string literals are not supported
--> $DIR/no-nuls.rs:29:7
|
LL | c"\u{00}";
| ^^^^^^
error: null characters in C string literals are not supported
--> $DIR/no-nuls.rs:30:7
|
Replace ASCII control chars with Unicode Control Pictures ``` error: bare CR not allowed in doc-comment --> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32 | LL | /// doc comment with bare CR: '␍' | ^ ```
2024-07-09 16:46:09 +00:00
LL | c"␀";
reimplement C string literals
2023-07-16 18:59:05 +00:00
| ^
update and add a few tests
2023-03-06 07:10:23 +00:00
Detect `NulInCStr` error earlier. 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-07 09:53:08 +11:00
error: null characters in C string literals are not supported
--> $DIR/no-nuls.rs:31:7
|
LL | c"\x00";
| ^^^^
error: null characters in C string literals are not supported
--> $DIR/no-nuls.rs:32:8
|
Replace ASCII control chars with Unicode Control Pictures ``` error: bare CR not allowed in doc-comment --> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32 | LL | /// doc comment with bare CR: '␍' | ^ ```
2024-07-09 16:46:09 +00:00
LL | cr"␀";
Detect `NulInCStr` error earlier. 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-07 09:53:08 +11:00
| ^
error: null characters in C string literals are not supported
--> $DIR/no-nuls.rs:37:14
|
LL | empty!(c"\0");
| ^^
error: null characters in C string literals are not supported
--> $DIR/no-nuls.rs:38:14
|
LL | empty!(c"\u{00}");
| ^^^^^^
error: null characters in C string literals are not supported
--> $DIR/no-nuls.rs:39:14
|
Replace ASCII control chars with Unicode Control Pictures ``` error: bare CR not allowed in doc-comment --> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32 | LL | /// doc comment with bare CR: '␍' | ^ ```
2024-07-09 16:46:09 +00:00
LL | empty!(c"␀");
Detect `NulInCStr` error earlier. 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-07 09:53:08 +11:00
| ^
error: null characters in C string literals are not supported
--> $DIR/no-nuls.rs:40:14
|
LL | empty!(c"\x00");
| ^^^^
error: null characters in C string literals are not supported
--> $DIR/no-nuls.rs:41:15
|
Replace ASCII control chars with Unicode Control Pictures ``` error: bare CR not allowed in doc-comment --> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32 | LL | /// doc comment with bare CR: '␍' | ^ ```
2024-07-09 16:46:09 +00:00
LL | empty!(cr"␀");
Detect `NulInCStr` error earlier. 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-07 09:53:08 +11:00
| ^
error: aborting due to 15 previous errors
update and add a few tests
2023-03-06 07:10:23 +00:00
Reference in New Issue Copy Permalink