Post-Merge Conflicts, Implementation Refinement, and Feature Stabilization

When your reviewer approves the PR, it will go into a queue for yet another bot called `@bors`. `@bors` manages the CI build/merge queue. When your PR reaches the head of the `@bors` queue, `@bors` will test out the merge by running all tests against your PR on GitHub Actions. This takes a lot of time to finish. If all tests pass, the PR is merged and becomes part of the next nightly compiler! There are a couple of things that may happen for some PRs during the review process - If the change is substantial enough, the reviewer may request an FCP on the PR. This gives all members of the appropriate team a chance to review the changes. - If the change may cause breakage, the reviewer may request a [crater] run. This compiles the compiler with your changes and then attempts to compile all crates on crates.io with your modified compiler. This is a great smoke test to check if you introduced a change to compiler behavior that affects a large portion of the ecosystem. - If the diff of your PR is large or the reviewer is busy, your PR may have some merge conflicts with other PRs that happen to get merged first. You should fix these merge conflicts using the normal git procedures. If you are not doing a new feature or something like that (e.g. if you are fixing a bug), then that's it! Thanks for your contribution :) ## Refining your implementation As people get experience with your new feature on nightly, slight changes may be proposed and unresolved questions may become resolved. Updates/changes go through the same process for implementing any other changes, as described above (i.e. submit a PR, go through review, wait for `@bors`, etc). Some changes may be major enough to require an FCP and some review by Rust team members. For the `?` macro feature, we went through a few different iterations after the original implementation: [1][impl2], [2][impl3], [3][impl4]. Along the way, we decided that `?` should not take a separator, which was previously an unresolved question listed in the RFC. We also changed the disambiguation strategy: we decided to remove the ability to use `?` as a separator token for other repetition operators (e.g. `+` or `*`). However, since this was a breaking change, we decided to do it over an edition boundary. Thus, the new feature can be enabled only in edition 2018. These deviations from the original RFC required [another FCP](https://github.com/rust-lang/rust/issues/51934). ## Stabilization Finally, after the feature had baked for a while on nightly, a language team member [moved to stabilize it][stabilizefcp]. A _stabilization report_ needs to be written that includes - brief description of the behavior and any deviations from the RFC - which edition(s) are affected and how - links to a few tests to show the interesting aspects The stabilization report for our feature is [here][stabrep]. After this, [a PR is made][stab] to remove the feature gate, enabling the feature by default (on the 2018 edition). A note is added to the [Release notes][relnotes] about the feature. Steps to stabilize the feature can be found at [Stabilizing Features](./stabilization_guide.md).

After a reviewer approves a PR, it enters the @bors queue for CI testing before merging. Larger PRs might encounter merge conflicts. Following the initial merge, features might undergo refinement through subsequent PRs and FCPs. Ultimately, a feature is stabilized after baking on nightly, involving a stabilization report, feature gate removal, and release notes. Steps for stabilizing a feature can be found in the [Stabilizing Features](./stabilization_guide.md) document.