-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
error for too many trailing #s in raw string literals could be improved #60762
Comments
Gonna work on it (my first work on the compiler internals, so please bear with me :) ) |
Feel free to ask for help! I feel both of these errors could be tweaked slightly:
and
The later might be harder to accomplish, needing to keep track of possible but incorrect closing spans (probably just looking for |
I indeed have a question @estebank. The fatal error itself is emitted at rust/src/libsyntax/parse/parser.rs Line 729 in 80e7cde
rust/src/libsyntax/parse/lexer/mod.rs Lines 1163 to 1240 in 80e7cde
I don't see how I can add labels to that error message without actually creating my own fatal which would most likely will end up in code duplication. Solutions I see:
This is what my solution currently looks like.
|
In addition to too many
I'm not sure about how to do that, if I just can use a span from the very beginning to the end and it will leave out the intermediate lines automatically or do I have to do something about that? On the other hand, is that even possible to detect? I don't know if one can find the end of this, except there an EOF. What do you think about this? |
I looked at the first implementation of this cc #48546 @GuillaumeGomez . What do you think about this? |
That might make things more clear, indeed. 👍 |
@hellow554, you should be able to synthesize a span that covers the entire closing sigil ( When supplying a span that covers multiple lines, the cli output will show the first 5(?) and last two lines of the covered span and draw the ascii art pointing at the start and end. The output you envision would happen by providing independent spans, and it's what I would prefer. For the too many
By doing this, the parser (the lexer, rather) will continue on its merry way and parse the rest of the file as if nothing had happened. |
Thanks estebank. That was very helpful indeed. I haven't thought of consuming the bad characters so that the lexer can do the rest for me. Very nice.
This is nice and looks very neat :) This is not a hidden suggestion as you see, is that okay for you as well? I mean, yes, it's kind of obvious which ones to remove, but I also like the expressiveness here. |
I also tried to add the text "The raw string has {} leading
Should I add an check if the raw string only spans over one line? If yes, how to do that? ^^ |
There are two options, either we don't use the full string's span (showing only the start and the end), or use I think a good output using the former approach would be:
With a hidden suggestion pointing at the last two
I'm ok with using visible suggestions when possible, but for borderline cases where the course of action is obvious and the output would be too cluttered, I'd lean towards hiding the suggestion. They will still be visible in VSCode and actionable by rustfix. |
Wow.. TIL the code for a raw string, aka rust/src/libsyntax/parse/lexer/mod.rs Lines 1369 to 1427 in 1962ade
rust/src/libsyntax/parse/lexer/mod.rs Lines 1139 to 1216 in 1962ade
I'm really going forward in this issue and I really like the architecture of the compiler (although it's confusing sometimes, because sometimes you need to pass a &str but sometimes a String which is kind of weird and has no reason, but meh... 🙄)
If you could me assist further with the error messages I would be happy. |
@hellow554 Of course! Feel free to reach out with whatever problem you might face. As for the output, I think the following should be ok for all cases (even though it hides a big of content in between that isn't strictly relevant):
|
@rustbot claim |
Ummm.... not what I expected, but okay.... @pietroalbini can you take a look at this? ^^ |
@hellow554 that's the correct behavior: you can't be assigned to the issue directly because GitHub only allows organization members to be assigned to issues. The only way we have to get around that is to assign the bot itself and add a note in the top message that you're actually the one assigned. |
Thanks for the clarification. I haven't seen the "This issue has been assigned to @hellow554 via this comment." in the top post. Thanks for that. |
@rustbot claim Working on this now, should have a diff in a few days |
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)
…rochenkov Improve error messages for raw strings (rust-lang#60762) 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) Fixes rust-lang#60762 cc @estebank who reviewed the original (abandoned) PR for the same ticket. r? @Centril
…rochenkov Improve error messages for raw strings (rust-lang#60762) 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) Fixes rust-lang#60762 cc @estebank who reviewed the original (abandoned) PR for the same ticket. r? @Centril
…rochenkov Improve error messages for raw strings (rust-lang#60762) 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) Fixes rust-lang#60762 cc @estebank who reviewed the original (abandoned) PR for the same ticket. r? @Centril
Rollup of 6 pull requests Successful merges: - rust-lang#70511 (Add `-Z dump-mir-dataflow` flag for dumping dataflow results visualization) - rust-lang#70522 (Improve error messages for raw strings (rust-lang#60762)) - rust-lang#70547 (Add `can_unwind` field to `FnAbi`) - rust-lang#70591 (Ensure LLVM is in the link path for "fulldeps" tests) - rust-lang#70627 (Use place directly its copy) - rust-lang#70652 (Add git repo address to unstable book) Failed merges: - rust-lang#70634 (Remove some reexports in `rustc_middle`) r? @ghost
for example (play)
results in
while too few has a much nicer error:
This issue has been assigned to @rcoh via this comment.
The text was updated successfully, but these errors were encountered: