Amend the template from RFC 1589 #2658
Conversation
practice of future-compatibility lints.
|
|
||
| - [ ] PR ? introduces the `YOUR_LINT_NAME_HERE` lint as warn-by-default | ||
| - [ ] PR ? makes the `YOUR_LINT_NAME_HERE` lint deny-by-default | ||
| - [ ] PR ? makes the `YOUR_LINT_NAE_HERE` lint a hard error | ||
|
|
There was a problem hiding this comment.
It would be nice to include:
Schedule
Describe the estimated schedule in terms of Rust releases for converting the warning to deny and then ultimately to a hard error.
There was a problem hiding this comment.
Has any summary issue for a future-incompatibility lint included such a schedule?
I don't mind preserving parts of the original RFC that were good ideas, nor do I mind codifying existing practice, but in my quick skim earlier, I don't recall any future-incompatibility specifying a schedule.
There was a problem hiding this comment.
Not to my knowledge, but I think it would be good to have schedules for the purpose of effective tracking and triage; standardization of such schedules as Niko notes below would also be helpful imo.
There was a problem hiding this comment.
Okay; I don't dispute the idea that we need to have a more upfront focus on the scheduling. If @nikomatsakis signs off on the text you drafted, then I'll add it to this PR.
But if its something that's going to want a lot of discussion/tweaking/bikeshedding, then I'd rather leave it to a different Pull Request.
|
The https://forge.rust-lang.org/rustc-bug-fix-procedure.html page also needs updating after this. :) |
|
|
||
| *Explain here what the developer needs to do to address the warning.* | ||
|
|
||
| #### Current status |
There was a problem hiding this comment.
On the other hand, this seems like an improvement, but perhaps a bit premature -- I'm not sure if we always take these three steps? Still, I like the idea of showing the process more graphically, and I think we should adopt a "standard" time frame that is tighter than the "open-ended process" suggested by the old template.
There was a problem hiding this comment.
We probably don't always take these steps but I think we often do and it seems like a good procedure :) -- I agree with standardizing the time-frame, or at the very least having a time-frame at all.
There was a problem hiding this comment.
So is there actually something for me to do here? I think starting with the provided three steps in the template makes more sense than leaving them out.
Do you want me to add an explicit note saying that people have the option to revise that section on a case-by-case basis?
…late. Since that initial paragraph includes the link to RFC 1589, I removed the suggestion (that I added) to include the link from the "What is this lint about" section.
|
I think the current state of this PR is good and we should merge this for now. Follow up work is discussed in https://rust-lang.zulipchat.com/#narrow/stream/185694-t-compiler.2Fwg-meta/topic/future-incompat.20planning. |
Centril
added
A-lint
Amend the issue template from text of RFC 1589 to match current actual practice of future-compatibility lints.
In particular, while working on rust-lang/rust#58608, I discovered that the current batch of C-future-compatibility tracking issues don't look anything like the template provided in this RFC.
So I took inspiration from one them (rust-lang/#57644 in particular) when composing my own rust-lang/rust#59014, but I wanted to back-propagate the template that seems to have evolved into the original RFC text so that people who use the RFC as the basis for their own issue will start off on the right foot.