Rust 2021 edition bug?

[Ethindp]

So, I've encountered a couple (very weird) problems that (I think) are bugs with the 2021 edition of Rust.

First, this code:

if cover & ((1<<(hi+1))-(1<<lo)) > 0 {
eprintln!("{}: overspecified ", name);
exit(1)
}

Generates a compiler error about unknown string prefixes if the trailing whitespace is removed. This doesn't make any sense to me at all, since the word is a suffix, not a prefix, and isn't within the {}, and I don't recall this ever being mentioned in the Rust 2021 blog post, and it is (not) the syntax described in the edition guide describing reserved syntax for the 2021 edition, so there is no reason that this error should be appearing.

Second, this code:

println!("Done");

(or any other string literal within the double quotes) generates error E0765 (unterminated double quote string). Again, this is a nonsensical error, and is (perfectly) valid rust. It is not reserved syntax nor does it violate any existing syntactic rules for the language. So I am extremely confused by this error. Am using Rust nightly (rustc 1.58.0-nightly (ff0e14829 2021-10-31)). Updating to rustc 1.58.0-nightly (0d1754e8b 2021-11-05) doesn't resolve the problem, nor does switching to stable or beta channels. Is this an actual bug or am I doing something wrong that I missed?

[steffahn]

I can't reproduce your problems. Can you reproduce it in the playground? Or could you provide your exact source file, e.g. as a Github gist?

[steffahn]

Ah.. perhaps you have an additional " (or a " missing) somewhere previously in your code!

Rust Playground

That's most easily avoided if you use an editor with syntax highlighting.

[Ethindp]

That solved the second error, thanks, I didn't notice that!. What about the first? I've never seen that before and it doesn't really make all that much sense.

[steffahn]

@Ethindp

That solved the second error, thanks, I didn't notice that!. What about the first?

Isn't that the same problem?

[Ethindp]

Oh yeah, it was, thanks! The compiler confused me!

[ekuber]

That's a nasty edge case!
I have no idea how we'd detect it gracefully

[steffahn]

Really, as I mentioned above, the by far easiest way to address this problem is syntax-highlighting. The programmer is going to be great at spotting where the code starts being string-highlighted and the strings start to be code-highlighted.

Maybe a heuristic in the compiler could somehow detect what's likely string-content and what's likely code and hint at or around the right area where a quotation mark would need to be inserted/removed? Sounds highly nontrivial though.

Maybe as a minimal viable feature, when a unterminated double quote string error is present anyways, point out strings spanning multiple lines? (This should be useful assuming that most string literals do not span multiple lines.)

Also maybe unterminated double quote string should be always on top of all other errors, since in the presence of incorrectly terminated strings, lots of other errors could just be noise distracting from the actual problem.

---

Edit: Playing around with misplaced "s some more, I feel like trying to give good diagnostics here is almost futile. For example I've now tested

fn main() {"
    if cover & ((1<<(hi+1))-(1<<lo)) > 0 {
        eprintln!(""{}: overspecified", name);
        exit(1)
    }
}

which only gives errors about mismatched parentheses which is super far away from the actual problem of what's going on here. It's almost impossible to fix code like this without using syntax highlighting; and once you use it, it's trivial to fix the problem

fn main() {"
    if cover & ((1<<(hi+1))-(1<<lo)) > 0 {
        eprintln!(""{}: overspecified", name);
        exit(1)
    }
}

fn main() {
    if cover & ((1<<(hi+1))-(1<<lo)) > 0 {
        eprintln!(""{}: overspecified", name);
        exit(1)
    }
}

fn main() {
    if cover & ((1<<(hi+1))-(1<<lo)) > 0 {
        eprintln!("{}: overspecified", name);
        exit(1)
    }
}

---

Hmm.. Possibly the compiler itself could just print out the code with some colored highlighting on where the strings are if it has reason to believe that misplaced "-s are a problem.

[ekuber]

The "check multiline strings" is similar to the approach we take for the unclosed delimiters check. I think it would work.

Adding syntax highlighting to the output could be possible, but it would have to be in a way with subtle colors (beyond ansi 16) and that works across the board. I feel like there are about a dozen features waiting on such ability to customize the local rustc env for fancier output

[quinedot]

I agree that multi-line string detection works in most cases I've made such typos.

say "foo;
say "bar";
exit 0;

Bareword found where operator expected at /tmp/perl.pl line 5, near "say "bar"
  (Might be a runaway multi-line "" string starting on line 4)
	(Do you need to predeclare say?)
String found where operator expected at /tmp/perl.pl line 5, at end of line
	(Missing semicolon on previous line?)
syntax error at /tmp/perl.pl line 5, near "say "bar"
Can't find string terminator '"' anywhere before EOF at /tmp/perl.pl line 5.