Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

underscore_literal_suffix future-compatibility warnings #42326

Closed
qnighy opened this issue May 31, 2017 · 3 comments · Fixed by #103914
Closed

underscore_literal_suffix future-compatibility warnings #42326

qnighy opened this issue May 31, 2017 · 3 comments · Fixed by #103914
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@qnighy
Copy link
Contributor

qnighy commented May 31, 2017

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.
qnighy added a commit to qnighy/rust that referenced this issue May 31, 2017
@qnighy
Add warning cycle rust-lang#42326.
0b8c3de
@qnighy qnighy mentioned this issue May 31, 2017
Merged
@nikomatsakis nikomatsakis added B-unstable Blocker: Implemented in the nightly compiler and unstable. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 31, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Jul 22, 2017
@Manishearth Manishearth mentioned this issue Mar 11, 2019
Open
@steveklabnik
Copy link
Member

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

@pnkfelix pnkfelix added the C-future-incompatibility Category: Future-incompatibility lints label Mar 18, 2022
@pnkfelix
Copy link
Member

pnkfelix commented Mar 18, 2022 •
edited
Loading

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

@rustbot rustbot added the S-tracking-needs-to-bake Status: The implementation is "complete" but it needs time to bake. label Mar 18, 2022
@nikomatsakis
Copy link
Contributor

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

@nnethercote nnethercote mentioned this issue Nov 3, 2022
Merged
JohnTitor pushed a commit to JohnTitor/rust that referenced this issue Nov 6, 2022
Rollup merge of rust-lang#103914 - nnethercote:close-42326, r=petroch…
ceff97a 
…enkov

Make underscore_literal_suffix a hard error.

It's been a warning for 5.5 years. Time to make it a hard error.

Closes rust-lang#42326.

r? `@pnkfelix`
JohnTitor pushed a commit to JohnTitor/rust that referenced this issue Nov 7, 2022
Rollup merge of rust-lang#103914 - nnethercote:close-42326, r=petroch…
19c780a 
…enkov

Make underscore_literal_suffix a hard error.

It's been a warning for 5.5 years. Time to make it a hard error.

Closes rust-lang#42326.

r? ``@pnkfelix``
@bors bors closed this as completed in dba6fc3 Nov 7, 2022
@dtolnay dtolnay removed the S-tracking-needs-to-bake Status: The implementation is "complete" but it needs time to bake. label Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Make underscore_literal_suffix a hard error. nnethercote/rust
7 participants
@steveklabnik @qnighy @nikomatsakis @pnkfelix @dtolnay @Mark-Simulacrum @rustbot