mirror
/
rustc-dev-guide
mirror of https://github.com/rust-lang/rustc-dev-guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Clean up section about FCPs (#1287) 

* I've never heard the term "pFCP" used before, so spell it out as
  "proposed final comment period"

* Fix some unclear things (like implying that you need `r+` rights to
  start an FCP)

* Improve the chapter's title, and make it consistent with its TOC entry

* Make some other assorted minor cleanups and improvements
This commit is contained in:
Noah Lev 2022-01-18 06:09:16 -08:00 committed by GitHub
parent 08019e25d1
commit ce956908d0
1 changed files with 19 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
src/implementing_new_features.md
View File

@ -1,43 +1,42 @@
# Implement New Feature # Implementing new features
When you want to implement a new significant feature in the compiler, When you want to implement a new significant feature in the compiler,
you need to go through this process to make sure everything goes you need to go through this process to make sure everything goes
smoothly. smoothly.
## The @rfcbot (p)FCP process ## The @rfcbot FCP process
When the change is small and uncontroversial, then it can be done When the change is small and uncontroversial, then it can be done
with just writing a PR and getting r+ from someone who knows that with just writing a PR and getting an r+ from someone who knows that
part of the code. However, if the change is potentially controversial, part of the code. However, if the change is potentially controversial,
it would be a bad idea to push it without consensus from the rest it would be a bad idea to push it without consensus from the rest
of the team (both in the "distributed system" sense to make sure of the team (both in the "distributed system" sense to make sure
you don't break anything you don't know about, and in the social you don't break anything you don't know about, and in the social
sense to avoid PR fights). sense to avoid PR fights).
If such a change seems to be too small to require a full formal RFC If such a change seems to be too small to require a full formal RFC process
process (e.g. a big refactoring of the code, or a (e.g., a small standard library addition, a big refactoring of the code, a
"technically-breaking" change, or a "big bugfix" that basically "technically-breaking" change, or a "big bugfix" that basically amounts to a
amounts to a small feature) but is still too controversial or small feature) but is still too controversial or big to get by with a single r+,
big to get by with a single r+, you can start a pFCP (or, if you you can propose a final comment period (FCP). Or, if you're not on the relevant
don't have r+ rights, ask someone who has them to start one - and team (and thus don't have @rfcbot permissions), ask someone who is to start one;
unless they have a concern themselves, they should). pFCP stands for unless they have a concern themselves, they should.
"proposed final comment period".
Again, the pFCP process is only needed if you need consensus - if you Again, the FCP process is only needed if you need consensus – if you
don't think anyone would have a problem with your change, it's ok to don't think anyone would have a problem with your change, it's OK to
get by with only an r+. For example, it is OK to add or modify get by with only an r+. For example, it is OK to add or modify
unstable command-line flags or attributes without a pFCP for unstable command-line flags or attributes without an FCP for
compiler development or standard library use, as long as you don't compiler development or standard library use, as long as you don't
expect them to be in wide use in the nightly ecosystem. expect them to be in wide use in the nightly ecosystem.
You don't need to have the implementation fully ready for r+ to ask You don't need to have the implementation fully ready for r+ to propose an FCP,
for a pFCP, but it is generally a good idea to have at least a proof but it is generally a good idea to have at least a proof
of concept so that people can see what you are talking about. of concept so that people can see what you are talking about.
When a pFCP is started, it requires all members of the team to sign off When an FCP is proposed, it requires all members of the team to sign off the
the FCP. After they all do so, there's a 10 day long "final comment FCP. After they all do so, there's a 10-day-long "final comment period" (hence
period" where everybody can comment, and if no new concerns are raised, the name) where everybody can comment, and if no concerns are raised, the
the PR/issue gets FCP approval. PR/issue gets FCP approval.
## The logistics of writing features ## The logistics of writing features
@ -79,7 +78,6 @@ feature can be changed, or the feature might be completely
rewritten or removed. Features are not supposed to gain tenure rewritten or removed. Features are not supposed to gain tenure
by being unstable and unchanged for a year. by being unstable and unchanged for a year.
<a name = "tracking-issue"></a>
### Tracking Issues ### Tracking Issues
To keep track of the status of an unstable feature, the To keep track of the status of an unstable feature, the
@ -111,7 +109,6 @@ for stabilization in a checklist, e.g.,
- [ ] Stabilize the feature. ([See instructions on rustc-dev-guide.](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr)) - [ ] Stabilize the feature. ([See instructions on rustc-dev-guide.](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr))
``` ```
<a name="stability-in-code"></a>
## Stability in code ## Stability in code
The below steps needs to be followed in order to implement The below steps needs to be followed in order to implement