Carriage return without line feed can be used to hide malicious code

The issue is basically in the title: rustc parses a carriage return ("\r") as a proper whitespace token. However, on some platforms/systems (for example cat in my linux terminal), the carriage return is interpreted as simply returning the cursor to the beginning of the line and overwriting what follows.

Hence the following file:

fn do_something_very_bad() {
     todo!()
}

fn main() {
     do_something_very_bad();\r    // No need to worry here, this looks very innocuous, I think nothing bad will happen
     println!("Oh hi! You should definitely run this very innocuous binary");
}

is displayed as

fn do_something_very_bad() {
     todo!()
}

fn main() {
     // No need to worry here, this looks very innocuous, I think nothing bad will happen
     println!("Oh hi! You should definitely run this very innocuous binary");
}

The security team and I agree that this does not qualify as a security issue.

In the past, we have added lint to safe-guard against CVE-2021-42574 (https://blog.rust-lang.org/2021/11/01/cve-2021-42574/), which is similar and was treated as a security issue. However to quote Pietro: "the main reason we treated [CVE-2021-42574] that way back then was that editors and code review tools didn't handle it at all, while most editors and code review sites seem to handle \r gracefully".

We may be opening a can of worm by trying to properly handle all Unicode messes that may lead to wrong displays of code across all possible systems allowing to read code, but I think it it nonetheless worth it to have the possibility of a discussion.

Start by reviewing how rustc tokenizes carriage returns and the existing lint added for CVE-2021-42574. The issue names no files or tests and leaves the desired handling open for discussion; done would require an agreed approach and corresponding validation for carriage-return source files.