-
Notifications
You must be signed in to change notification settings - Fork 13.8k
Closed
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Description
for example (play)
let foo = r##"bar"###;
results in
error: expected one of `.`, `;`, `?`, or an operator, found `#`
--> src/main.rs:2:25
|
2 | let foo = r##"bar"###;
| ^ expected one of `.`, `;`, `?`, or an operator here
while too few has a much nicer error:
error: unterminated raw string
--> src/main.rs:3:15
|
3 | let baz = r##"quxx"#;
| ^ unterminated raw string
|
= note: this raw string should be terminated with `"##`
This issue has been assigned to @rcoh via this comment.
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Activity
hellow554 commentedon May 13, 2019
Gonna work on it (my first work on the compiler internals, so please bear with me :) )
estebank commentedon May 13, 2019
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
"#
in the string being processed). This seems like a different enough task, and harder enough to be worthy of a separate PR.hellow554 commentedon May 14, 2019
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:
* downside would be code duplication and increased complexity
* plus would be, same error message as before
* downside, more text,
* plus, very little additional code needed
* downside, another error, which might ne not suitable, because the current one is already very good
* plus, very little additional code needed
This is what my solution currently looks like.
hellow554 commentedon May 14, 2019
In addition to too many
#
, I was looking at the case where there are less#
than expected, but not in the same line, but over a lot of lines (in my newly added testcase there are 18 lines now).I would like to improve that error message as well, something like:
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?
hellow554 commentedon May 14, 2019
I looked at the first implementation of this cc #48546 @GuillaumeGomez . What do you think about this?
GuillaumeGomez commentedon May 14, 2019
That might make things more clear, indeed. 👍
estebank commentedon May 14, 2019
@hellow554, you should be able to synthesize a span that covers the entire closing sigil (
"####
) where we look for it and break if we don't find it. We should hold a vec of spans that we add to every time we find them, because it is possible that we indeed have a raw string that contains"#
multiple times and we can't assume that the first we find is correct. We could have some extra smarts in case we were writing something liker###"r##"r#""#"##"###
orr###"r##"r#""#"#"#
to avoid suggesting all three closing spans, but for now the naïve way should be fine.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
#
at the end, you could proactively look for them before thebreak
, by following case 1 and using something likeBy 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.
hellow554 commentedon May 15, 2019
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.
I'm a bit undecided where the journey goes. Currently I have this:
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.
hellow554 commentedon May 15, 2019
I also tried to add the text "The raw string has {} leading
#
", but it looks very crowded to me, when the raw string only is one line.Should I add an check if the raw string only spans over one line? If yes, how to do that? ^^
estebank commentedon May 15, 2019
There are two options, either we don't use the full string's span (showing only the start and the end), or use
is_multiline
to provide different output depending on the visual result.I think a good output using the former approach would be:
With a hidden suggestion pointing at the last two
#
to avoid clutter.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.
backtrace
crate from crates.io #60852hellow554 commentedon May 16, 2019
That looks very promising!
The only thing is (that bugs me a little bit) are the
^^^
between the----
.but I haven't found a way to get rid of them. I think it's okay, but they are not needed IMHO. Time to work on the other suggestion!
Reducing the error span to only the ending `# symbols does not look nice for multi line string literals.
Therefore I'm afraid that's not an option. Any other way to get a nice result?
16 remaining items
Rollup merge of rust-lang#70522 - rcoh:60762-raw-string-errors, r=pet…
Rollup merge of rust-lang#70522 - rcoh:60762-raw-string-errors, r=pet…
Rollup merge of rust-lang#70522 - rcoh:60762-raw-string-errors, r=pet…