Add new lint octal_escapes

[birkenfeld]

This checks for sequences in strings that would be octal character
escapes in C, but are not supported in Rust. It suggests either
to use the \x00 escape, or an equivalent hex escape if the octal
was intended.

Fixes #7981

---

Please write a short comment explaining your change (or "none" for internal only changes)

changelog: Add new lint [octal_escapes], which checks for literals like "\033[0m".

[rust-highfive]

r? @xFrednet

(rust-highfive has picked a reviewer for you, use r? to override)

[xFrednet]

Thank you for the PR, the general structure is already good IMO :)

[birkenfeld]

Ok, I think I got all the requested changes.

However, I just found a pretty unfortunate problem: the format strings of println! and friends are not recognized, because at the point of the check, "\033" is already normalized to "\u{0}33" - I don't know where this happens. Is there any way to catch this?

[xFrednet]

The logic looks good to me! I've marked to more test cases which would be good to have, then it's ready to be merged 🙃

[xFrednet]

In the past, Clippy had some errors with string indexing and Unicode characters. This should be safe, could you still add these test cases to ensure that is stays stable:

let _test_unicode = "锈\011锈"
let _test_unicode = "锈\01锈"

[birkenfeld]

Of course, that's a good point.

[xFrednet]

However, I just found a pretty unfortunate problem: the format strings of println! and friends are not recognized, because at the point of the check, "\033" is already normalized to "\u{0}33" - I don't know where this happens. Is there any way to catch this?

Interesting. @camsteffen I think you worked with the format! macro quite a bit recently, do you maybe have an idea for this? We could use snip the get the original string literal, but that would be a bit hacky 🤔

[camsteffen]

This is a problem that has come up a few times. Format strings are just not available in their original form in post-expanded code. So I don't have a neat solution unfortunately. Getting a snippet and parsing it is indeed hacky and I think we should avoid re-parsing the string from scratch.

[xFrednet]

Getting a snippet and parsing it is indeed hacky and I think we should avoid reparsing the string from scratch.

Agreed, then that's just something we accept. It might be good to add this to the Known problems section @birkenfeld, could you maybe do this as well? 😅

[xFrednet]

Looks good to me, thank you for the implementation and for the adjustments. I like this final version!

@bors r+

[bors]

📌 Commit 1210bb4 has been approved by xFrednet

[bors]

⌛ Testing commit 1210bb4 with merge 57a8804...

[birkenfeld]

Thanks! It was fun getting back to clippy after quite a few years :)

[xFrednet]

Happy to hear that it's nice to have you back! I just looked back into the history, and you were a really early contributor. That's really awesome to see. The project and codebase probably changed quite a bit since back then ^^

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: xFrednet
Pushing 57a8804 to master...