Display better snippet for invalid char literal #30763
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Ideally, the span would not include the |
|
@apasel422 ok - sure thing. |
|
To me it seems we should investigate why |
|
Investigating the failing test now. @nagisa if I understand it correctly, |
|
I agree with @nagisa that the Would it be possible to fix the span without the scan backwards function? |
|
@alexcrichton sure thing. I'll dig into it and update the PR! |
You could introduce another variable earlier in the function (or rename the |
|
@nagisa I did try that before I ended up with the current iteration. Even at the very beginning of the function the start variable was not in the right place. I might have just overlooked something though. I'll go back and try it again and see what I find. Will update here when I have something to report. Thanks for the feedback! |
|
@nagisa & @alexcrichton - I've fixed the problem and updated the PR. See the latest commit message for details on the fix. Basically we were exiting the function too early, without checking for a closing single quote. The latest commit makes the others which preceeded it unecessary. Should I squash them all together? Or is it ok to leave as is? |
|
☔ The latest upstream changes (presumably #30684) made this pull request unmergeable. Please resolve the merge conflicts. |
| @@ -1 +1 @@ | |||
| Subproject commit 95d6a00134f284e6b889d98f4c2cb4b285950327 | |||
| Subproject commit e0c0bf439add63a6a25a25ba47e4aec9547bf9af | |||
There was a problem hiding this comment.
This showed up when I rebased. Not sure how to make it not show up as part of this pull request...
There was a problem hiding this comment.
cd src/liblibc
git checkout 95d6a00134f284e6b889d98f4c2cb4b285950327
cd ../../
git add/commit --amend
is the crudest way which should work, I think.
|
Ok, updated from comments. Let me know what other tests you'd like, if any. Thanks! |
|
Yeah, a squash is necessary. Perhaps also a test for |
|
@nagisa having some issues getting the error right for I could try parse forwards until the end of the escape sequence? I'd need to do that any number of times, though depending on the number of sequences found. Take this example: Should I just recursively parse escape sequences? |
|
My suggestion would be to not parse until the end – you already know what’s the error and where it is happening, you just need to ensure the error is well worded. Current nightly outputs something like: It might be best to fall-back on error of this sort if you can’t immediately tell whether the literal is not terminated (i.e. missing EDIT: it could also be that we do not really want the “literal may only contain one codepoint” error and would rather always report the “unterminated character constant” instead and print an associated help message. For example: … at least for the non-lifetime case. |
|
@nagisa ok, sounds good. Will update the PR shortly. Thanks! |
Given this code:
fn main() {
let _ = 'abcd';
}
The compiler would give a message like:
error: character literal may only contain one codepoint: ';
let _ = 'abcd';
^~
With this change, the message now displays:
error: character literal may only contain one codepoint: 'abcd'
let _ = 'abcd'
^~~~~~
Fixes rust-lang#30033
|
@bors r+ |
|
📌 Commit acc9428 has been approved by |
|
Thanks, the PR turned out nicely! |
|
Thank you! Appreciate you going through it with me :) |
|
⌛ Testing commit acc9428 with merge 0cc6f21... |
|
💔 Test failed - auto-mac-64-nopt-t |
|
@bors retry Seems like its one of the spurious errors we've been having lately.
|
This is achieved by adding the scan_back method. This method looks back
through the source_text of the StringReader until it finds the target
char, returning it's offset in the source. We use this method to find
the offset of the opening single quote, and use that offset as the start
of the error.
Given this code:
```rust
fn main() {
let _ = 'abcd';
}
```
The compiler would give a message like:
```
error: character literal may only contain one codepoint: ';
let _ = 'abcd';
^~
```
With this change, the message now displays:
```
error: character literal may only contain one codepoint: 'abcd';
let _ = 'abcd';
^~~~~~~
```
Fixes #30033
This is achieved by adding the scan_back method. This method looks back
through the source_text of the StringReader until it finds the target
char, returning it's offset in the source. We use this method to find
the offset of the opening single quote, and use that offset as the start
of the error.
Given this code:
The compiler would give a message like:
With this change, the message now displays:
Fixes #30033