Skip to content

Update feature gating docs to fit reality #455

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Oct 1, 2019
Merged

Update feature gating docs to fit reality #455

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
19 changes: 14 additions & 5 deletions src/implementing_new_features.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ of concept so that people can see what you are talking about.

That starts a "proposed final comment period" (pFCP), which requires
all members of the team to sign off the FCP. After they all do so,
there's a week long "final comment period" where everybody can comment,
there's a 10 day long "final comment period" where everybody can comment,
and if no new concerns are raised, the PR/issue gets FCP approval.

## The logistics of writing features
Expand Down Expand Up @@ -119,10 +119,13 @@ a new unstable feature:
1. Open a [tracking issue] -
if you have an RFC, you can use the tracking issue for the RFC.

The tracking issue should be labeled with at least `C-tracking-issue`.
For a language feature, a label `F-feature_name` should be added as well.

2. Pick a name for the feature gate (for RFCs, use the name
in the RFC).

3. Add a feature gate declaration to `libsyntax/feature_gate.rs`
3. Add a feature gate declaration to `libsyntax/active.rs`
in the active `declare_features` block:

```rust,ignore
Expand All @@ -140,8 +143,8 @@ For example:
( active, match_beginning_vert, "1.21.0", Some(44101), None),
```

The current version is not actually important – the important
version is when you are stabilizing a feature.
When added, the current version should be the one for the current nightly.
Once the feature is moved to `accepted.rs`, the version is changed to that nightly version.

4. Prevent usage of the new feature unless the feature gate is set.
You can check it in most places in the compiler using the
Expand All @@ -153,10 +156,14 @@ version is when you are stabilizing a feature.
the pre-feature behavior or raise an error, depending on
what makes sense.

For features introducing new syntax, pre-expansion gating should be used instead.
To do so, extend the [`GatedSpans`] struct, add spans to it during parsing,
and then finally feature-gate all the spans in [`feature_gate::check::check_crate`].

5. Add a test to ensure the feature cannot be used without
a feature gate, by creating `feature-gate-$feature_name.rs`
and `feature-gate-$feature_name.stderr` files under the
`src/test/ui/feature-gates` directory.
directory where the other tests for your feature reside.

6. Add a section to the unstable book, in
`src/doc/unstable-book/src/language-features/$feature_name.md`.
Expand All @@ -167,6 +174,8 @@ version is when you are stabilizing a feature.
8. Get your PR reviewed and land it. You have now successfully
implemented a feature in Rust!

[`GatedSpans`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.GatedSpans.html
[`feature_gate::check::check_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/check/fn.check_crate.html
[value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md
[stability in code]: #stability-in-code
[here]: https://rust-lang.github.io/rustc-guide/stabilization_guide.html
Expand Down