Skip to content

Add an issue template for future-incompatible lints #140904

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 54 additions & 0 deletions .github/ISSUE_TEMPLATE/tracking_issue_future.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
---
name: Future Incompatibility Tracking Issue
about: A tracking issue for a future-incompatible lint
title: Tracking Issue for future-incompatibility lint XXX
labels: C-tracking-issue C-future-incompatibility T-compiler A-lints
---
<!--
Thank you for creating a future-incompatible tracking issue! 📜 These issues
are for lints that implement a future-incompatible warning.

Remember to add team labels to the tracking issue.
For something that affects the language, this would be `T-lang`, and for libs
it would be `T-libs-api`.
Also check for any `A-` labels to add.
-->

This is the **tracking issue** for the `YOUR_LINT_NAME_HERE` 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. For more information on the policy around future-compatibility warnings, see our [breaking change policy guidelines][guidelines].
Copy link
Member

@jieyouxu jieyouxu May 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussion: usually other tracking issues avoid encouraging detailed discussions on the tracking issue because it quickly becomes impossible to manage and usually there's no one around to actively summarize (esp. when it starts to collapse comments and backlinks extending the page height). Maybe instead have a section like "### Discussions and concerns" where dedicated issues for specific topics are backlinked to this main tracking issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, there are tradeoffs here. To be clear, this is from the RFC.

I agree that regular tracking issues are not well suited for discussion. However, I think a large part of these FCW issues is to solicit input from users. I can appreciate having a relatively lightweight means for people to leave comments about their concerns or questions. Unlike regular tracking issues, I suspect users won't be subscribing to the issue to receive updates since I doubt anyone will be looking forward to them closing (they aren't introducing new features people are excited about). And thus I'm not too concerned about it being spammy. I think if the issue does a good job of explaining the FCW and what is happening and why, then there should be fewer reasons for people to ask questions.

But if the team wants to change the process, I can update the text.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fine. If we find that it becomes too spammy in practice, we can always:

  • Change this template
  • Lock the original tracking issue, and explicitly fork off separate discussion issues.


[guidelines]: https://rustc-dev-guide.rust-lang.org/bug-fix-procedure.html

### What is the warning for?

*Describe the conditions that trigger the warning.*

### Why was this change made?

*Explain why this change was made. If there is additional context, like an MCP, link it here.*

### Example

```rust
// Include an example here.
```

### Recommendations

*Give some recommendations on how a user can avoid the lint.*

### When will this warning become a hard error?

*If known, describe the future plans. For example, how long you anticipate this being a warning, or if there are other factors that will influence the anticipated closure.*

### Steps

- [ ] Implement the lint
- [ ] Raise lint level to deny
- [ ] Make lint report in dependencies
- [ ] Switch to a hard error

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the lint.
-->
36 changes: 3 additions & 33 deletions src/doc/rustc-dev-guide/src/bug-fix-procedure.md
Original file line number Diff line number Diff line change
Expand Up @@ -80,41 +80,11 @@ approachable and practical; it may make sense to direct users to an RFC or some
other issue for the full details. The issue also serves as a place where users
can comment with questions or other concerns.

A template for these breaking-change tracking issues can be found below. An
example of how such an issue should look can be [found
A template for these breaking-change tracking issues can be found
[here][template]. An example of how such an issue should look can be [found
here][breaking-change-issue].

The issue should be tagged with (at least) `B-unstable` and `T-compiler`.

### Tracking issue template

This is a template to use for tracking issues:

```
This is the **summary issue** for the `YOUR_LINT_NAME_HERE`
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. For
more information on the policy around future-compatibility warnings,
see our [breaking change policy guidelines][guidelines].

[guidelines]: LINK_TO_THIS_RFC

#### What is the warning for?

*Describe the conditions that trigger the warning and how they can be
fixed. Also explain why the change was made.**

#### 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.
```
[template]: https://github.com/rust-lang/rust/issues/new?template=tracking_issue_future.md

### Issuing future compatibility warnings

Expand Down
Loading