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.

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

Tracking issue for future-incompatbility warning 'invalid literal suffix on tuple index' (not a lint) #60210

Open
nikomatsakis opened this issue Apr 23, 2019 · 3 comments
Labels
A-frontend Area: frontend (errors, parsing and HIR) A-parser Area: The parsing of Rust source code to an AST. C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Apr 23, 2019

This is the summary issue for a bug fix related to tuple indexing. 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. For more information on the policy around future-compatibility warnings, see our breaking change policy guidelines.

What is the warning for?

As reported in #59418, the compiler incorrectly accepts foo.0_u32 (and other suffixes) when indexing into tuples. The expected syntax is simply foo.0. We are presently issuing warnings when this incorrect syntax is used but we expect to transition those warnings to errors in the future.

How can you fix your code?

Most often this error manifests in procedural macros that employ the syn or quote crates. It can be avoided by using syn::Index::from or proc_macro::Literal::*_unsuffixed. For example, if before you were generating foo.0 doing something like this:

let i = 0;
quote! { foo.$i }

you might now do instead:

let i = syn::Index::from(0);
quote! { foo.$i }

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.

Related bugs

Here are some of the regressions found in the wild:

@Centril Centril added C-future-incompatibility Category: Future-incompatibility lints A-parser Area: The parsing of Rust source code to an AST. A-frontend Area: frontend (errors, parsing and HIR) labels Apr 23, 2019
nikomatsakis added a commit to nikomatsakis/lark that referenced this issue May 4, 2019
The existing behavior only worked because of rust-lang/rust#60210.
aldanor added a commit to aldanor/hdf5-rust that referenced this issue Jul 14, 2019
bors added a commit that referenced this issue Aug 3, 2019
Transition some C-future-compatibility lints to {ERROR, DENY}

Closes #40107 (ERROR).
Closes #39207 (ERROR).
Closes #37872 (ERROR).
Closes #36887 (ERROR).
Closes #36247 (ERROR.
Closes #42238 (ERROR).
Transitions #59014 (DENY).
Transitions #57571 (DENY).
Closes #60210 (ERROR).
Transitions #35203 (DENY).

r? @petrochenkov
Aaron1011 added a commit to Aaron1011/pin-project that referenced this issue Aug 8, 2019
@jonas-schievink jonas-schievink added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Apr 21, 2020
@lahwran

This comment has been minimized.

@roblabla
Copy link
Contributor

It appears to be impossible to promote this warning to an error? I've been trying to write a regression test in a proc macro to catch this error, but to no avail. See https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=933b66f963f15bda1c3b62d0ae19e517

RSSchermer added a commit to RSSchermer/empa that referenced this issue Oct 23, 2023
@fmease fmease added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. labels Sep 14, 2024
@fmease
Copy link
Member

fmease commented Sep 14, 2024

It appears to be impossible to promote this warning to an error? I've been trying to write a regression test in a proc macro to catch this error, but to no avail. See https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=933b66f963f15bda1c3b62d0ae19e517

Good catch! This warning was never assigned to a specific lint (whether intentional or not). We should address that.

@fmease fmease changed the title tuple indexing future compatibility warning Tracking issue for future-incompatbility warning 'invalid literal suffix on tuple index' Sep 14, 2024
@fmease fmease removed the A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. label Sep 14, 2024
@fmease fmease changed the title Tracking issue for future-incompatbility warning 'invalid literal suffix on tuple index' Tracking issue for future-incompatbility warning 'invalid literal suffix on tuple index' (not a lint) Sep 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: frontend (errors, parsing and HIR) A-parser Area: The parsing of Rust source code to an AST. C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

6 participants