Skip to content

underscore_literal_suffix future-compatibility warnings #42326

Closed

Description

@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.

Activity

  1. added a commit that references this issue on May 31, 2017
  2. added
    B-unstableBlocker: Implemented in the nightly compiler and unstable.
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on May 31, 2017
  3. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Jul 22, 2017
  4. steveklabnik commented on Mar 12, 2019

    @steveklabnik
    Contributor

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

  5. pnkfelix commented on Mar 18, 2022

    @pnkfelix
    Contributor

    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

  6. nikomatsakis commented on Mar 18, 2022

    @nikomatsakis
    Contributor

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

  7. added 2 commits that reference this issue on Nov 6, 2022
    ceff97a
    19c780a
  8. removed
    S-tracking-needs-to-bakeStatus: The implementation is "complete" but it needs time to bake.
    on Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-unstableBlocker: Implemented in the nightly compiler and unstable.C-future-incompatibilityCategory: Future-incompatibility lintsC-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions