Rollup merge of #140904 - ehuss:future-incompat-template, r=Mark-Simulacrum

Add an issue template for future-incompatible lints

This adds a GitHub issue template for future-incompatible lints. Most of the existing tracking issues have been using different formats with different information, and I think it would be helpful to make them a little more consistent and to ensure that sufficient information is provided.

Some comments on my choices:
* Added a dedicated section to describe *why* the change is being made. Many existing issues already have this, so let's standardize on it.
* Have a section with a very clear example. Almost all of the existing issues have this in one form or another.
* Added a "Recommendations" section, since this is something I see missing in several of the existing issues, and this is really important information IMHO.
* I reworded the "When" section. The existing template mentioned that these get reviewed every 6 weeks which my understanding is not true. That's also not very helpful information to the user, since it doesn't really answer the question. I'm not sure this section will actually be useful since I suspect most of the time we don't know when it will change (there have been a few exceptions).
* Clearly show the expected progression steps. Several issues already have this.
* Added implementation history, which is useful for linking PRs. (IDK, this could get merged with "Steps".)
This commit is contained in:
Matthias Krüger 2025-05-14 18:43:38 +02:00 committed by GitHub
commit 278937a7a8
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 3 additions and 33 deletions

View File

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