Suggestion for type mismatch when we need a u8 but the programmer wrote a char literal

[tialaramex]

Today Rust just points out that we have a char and we need a u8, but if I wrote 'A' then I could fix this by just writing b'A' instead. This code should detect the case where we're about to report a type mismatch of this kind, and the programmer wrote a char literal, and the char they wrote is ASCII, so therefore just prefixing b to make a byte literal will do what they meant.

I have definitely written this mistake more than once, it's not difficult to figure out what to do, but the compiler might as well tell us anyway.

I provided a test with two simple examples where the suggestion is appropriate, and one where it is not because the char literal is not ASCII, showing that the suggestion is only triggered in the former cases.

I have contributed only a small typo doc fix before, so this is my first substantive rustc change.

[rustbot]

r? @eholk

(rustbot has picked a reviewer for you, use r? to override)

[tialaramex]

Aha, I need to update the tests as well, working on that now.

[Noratrieb]

r? Nilstrieb
Thanks, that looks great! One last thing: could you squash your commits into one? I'll approve it afterwards. If you need help doing that, feel free to ask here

[Noratrieb]

@bors r+ rollup

[bors]

📌 Commit 130d02b has been approved by Nilstrieb

It is now in the queue for this repository.

[ayosec]

The suggestion is broken if the character is non-ASCII, but the sequence starts with \.

For example, the following code (playground):

fn f(_c: u8) {}

fn main() {
    f('\u{1234}');
}

Produces this message:

help: if you meant to write a byte literal, prefix with `b`
  |
4 |     f(b'\u{1234}');
  |       ~~~~~~~~~~~

But the proposed change does not compile:

  |
4 |     f(b'\u{1234}');
  |         ^^^^^^^^ unicode escape in byte string
  |

---

Sorry for writing this in a closed merge-request (I just saw this patch in a HNews thread). I can open a new issue if necessary.

[tialaramex]

Rats. I will look at whether I can improve this code but likely not before this weekend. Knew I should have checked an escaped literal like this :/

[tialaramex]

#107709 proposed, thanks again ayosec for spotting the problem