underscore_literal_suffix future-compatibility warnings

[qnighy]

This is the summary issue for the UNDERSCORE_LITERAL_SUFFIX future-compatibility warning and other related errors. The goal of this page is describe why this change was made and how you can fix
code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made.

What is the warning for?

The underscore_literal_suffix warning is issued when you use _ as a literal suffix. Due to the behavior of the lexer, this is limited to these two situations:

• After char/string/byte/bytestring literals: "Foo"_
• After float literals ending with .: 1._ (this kind of construction is already banned by means of Disallow ._ in float literal. #41946)

This warning can always be fixed by removing the _ and inserting whitespaces if necessary.

When will this warning become a hard error?

At the beginning of each 6-week release cycle, the Rust compiler team
will review the set of outstanding future compatibility warnings and
nominate some of them for Final Comment Period. Toward the end of
the cycle, we will review any comments and make a final determination
whether to convert the warning into a hard error or remove it
entirely.

[steveklabnik]

Triage: it's been a few years, and looks like nobody has visited this issue.

[pnkfelix]

Visiting as part of T-compiler backlog bonanza.

This lint appears implemented, perhaps via a span_warn. I do not yet know if the warning it reports is included as part of a cargo report future-incompat; I can look into that later.

The current diagnostic output indicates that it is probably not using the usual lint infrastructure (that would enable using allow/deny etc).

Next steps are

1. Run crater on experiementally moving it to hard error, to evaluate fallout.
2. If fallout is non-trivial, then it needs to be moved to a proper lint based implementation
3. Likewise, if fallout is non-trival, then ensure that it is included in the cargo report future-incompat output, when relevant.
4. If fallout is trivial, then we can just move to hard error without going through the longer route of replacing with a lint and whatnot.

@rustbot label: +S-tracking-needs-to-bake

[nikomatsakis]

@pnkfelix is this "needs to bake"? It feels like we are ready to take next steps here (running on crater).