Skip to content

Commit bd008cc

Browse files
authored
Document how to stabilize a library feature (#1036)
* Move 'force-unstable-if-unmarked' to the bootstrapping chapter * Document how to stabilize a library feature Note that features can't be stabilized until they go through FCP and that FCP happens on the tracking issue, not the PR. * Fix wrong glob By default `**` behaves the same as two `*` side by side, i.e. it only globs file paths, not directories. `shopt -s globstar` needs to be set for it to mean a directory. I didn't notice this before now because `globstar` is set by default in interactive mode, but not otherwise.
1 parent 85c995d commit bd008cc

File tree

4 files changed

+55
-36
lines changed

4 files changed

+55
-36
lines changed

ci/check_line_lengths.sh

+1
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,7 @@ if [ "$MAX_LINE_LENGTH" == "" ]; then
1010
fi
1111

1212
if [ "$1" == "" ]; then
13+
shopt -s globstar
1314
files=( src/**/*.md )
1415
else
1516
files=( "$@" )

src/building/bootstrapping.md

+30
Original file line numberDiff line numberDiff line change
@@ -313,12 +313,42 @@ of the public API of the standard library, but are used to implement it.
313313
`rustlib` is part of the search path for linkers, but `lib` will never be part
314314
of the search path.
315315

316+
#### -Z force-unstable-if-unmarked
317+
316318
Since `rustlib` is part of the search path, it means we have to be careful
317319
about which crates are included in it. In particular, all crates except for
318320
the standard library are built with the flag `-Z force-unstable-if-unmarked`,
319321
which means that you have to use `#![feature(rustc_private)]` in order to
320322
load it (as opposed to the standard library, which is always available).
321323

324+
The `-Z force-unstable-if-unmarked` flag has a variety of purposes to help
325+
enforce that the correct crates are marked as unstable. It was introduced
326+
primarily to allow rustc and the standard library to link to arbitrary crates
327+
on crates.io which do not themselves use `staged_api`. `rustc` also relies on
328+
this flag to mark all of its crates as unstable with the `rustc_private`
329+
feature so that each crate does not need to be carefully marked with
330+
`unstable`.
331+
332+
This flag is automatically applied to all of `rustc` and the standard library
333+
by the bootstrap scripts. This is needed because the compiler and all of its
334+
dependencies are shipped in the sysroot to all users.
335+
336+
This flag has the following effects:
337+
338+
- Marks the crate as "unstable" with the `rustc_private` feature if it is not
339+
itself marked as stable or unstable.
340+
- Allows these crates to access other forced-unstable crates without any need
341+
for attributes. Normally a crate would need a `#![feature(rustc_private)]`
342+
attribute to use other unstable crates. However, that would make it
343+
impossible for a crate from crates.io to access its own dependencies since
344+
that crate won't have a `feature(rustc_private)` attribute, but *everything*
345+
is compiled with `-Z force-unstable-if-unmarked`.
346+
347+
Code which does not use `-Z force-unstable-if-unmarked` should include the
348+
`#![feature(rustc_private)]` crate attribute to access these force-unstable
349+
crates. This is needed for things that link `rustc`, such as `miri`, `rls`, or
350+
`clippy`.
351+
322352
You can find more discussion about sysroots in:
323353
- The [rustdoc PR] explaining why it uses `extern crate` for dependencies loaded from sysroot
324354
- [Discussions about sysroot on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/deps.20in.20sysroot/)

src/stability.md

+19-36
Original file line numberDiff line numberDiff line change
@@ -44,12 +44,8 @@ prevents breaking dependencies by leveraging Cargo's lint capping.
4444
[rustc bug]: https://github.com/rust-lang/rust/issues/15702
4545

4646
## stable
47-
4847
The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly
49-
marks an item as stabilized. To do this, follow the instructions in
50-
[Stabilizing Features](./stabilization_guide.md).
51-
52-
Note that stable functions may use unstable things in their body.
48+
marks an item as stabilized. Note that stable functions may use unstable things in their body.
5349

5450
## rustc_const_unstable
5551

@@ -72,6 +68,24 @@ even on an `unstable` function, if that function is called from another
7268
Furthermore this attribute is needed to mark an intrinsic as callable from
7369
`rustc_const_stable` functions.
7470

71+
## Stabilizing a library feature
72+
73+
To stabilize a feature, follow these steps:
74+
75+
0. Ask a **@T-libs** member to start an FCP on the tracking issue and wait for
76+
the FCP to complete (with `disposition-merge`).
77+
1. Change `#[unstable(...)]` to `#[stable(since = "version")]`.
78+
`version` should be the *current nightly*, i.e. stable+2. You can see which version is
79+
the current nightly [on Forge](https://forge.rust-lang.org/#current-release-versions).
80+
2. Remove `#![feature(...)]` from any test or doc-test for this API. If the feature is used in the
81+
compiler or tools, remove it from there as well.
82+
3. If applicable, change `#[rustc_const_unstable(...)]` to
83+
`#[rustc_const_stable(since = "version")]`.
84+
4. Open a PR against `rust-lang/rust`.
85+
- Add the appropriate labels: `@rustbot modify labels: +T-libs`.
86+
- Link to the tracking issue and say "Closes #XXXXX".
87+
88+
You can see an example of stabilizing a feature at [#75132](https://github.com/rust-lang/rust/pull/75132).
7589

7690
## allow_internal_unstable
7791

@@ -130,35 +144,4 @@ default `allow`, but most of the standard library raises it to a warning with
130144
`#![warn(deprecated_in_future)]`.
131145

132146
[`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute
133-
134-
## -Z force-unstable-if-unmarked
135-
136-
The `-Z force-unstable-if-unmarked` flag has a variety of purposes to help
137-
enforce that the correct crates are marked as unstable. It was introduced
138-
primarily to allow rustc and the standard library to link to arbitrary crates
139-
on crates.io which do not themselves use `staged_api`. `rustc` also relies on
140-
this flag to mark all of its crates as unstable with the `rustc_private`
141-
feature so that each crate does not need to be carefully marked with
142-
`unstable`.
143-
144-
This flag is automatically applied to all of `rustc` and the standard library
145-
by the bootstrap scripts. This is needed because the compiler and all of its
146-
dependencies are shipped in the sysroot to all users.
147-
148-
This flag has the following effects:
149-
150-
- Marks the crate as "unstable" with the `rustc_private` feature if it is not
151-
itself marked as stable or unstable.
152-
- Allows these crates to access other forced-unstable crates without any need
153-
for attributes. Normally a crate would need a `#![feature(rustc_private)]`
154-
attribute to use other unstable crates. However, that would make it
155-
impossible for a crate from crates.io to access its own dependencies since
156-
that crate won't have a `feature(rustc_private)` attribute, but *everything*
157-
is compiled with `-Z force-unstable-if-unmarked`.
158-
159-
Code which does not use `-Z force-unstable-if-unmarked` should include the
160-
`#![feature(rustc_private)]` crate attribute to access these force-unstable
161-
crates. This is needed for things that link `rustc`, such as `miri`, `rls`, or
162-
`clippy`.
163-
164147
[blog]: https://www.ralfj.de/blog/2018/07/19/const.html

src/stabilization_guide.md

+5
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,10 @@
11
# Request for stabilization
22

3+
**NOTE**: this page is about stabilizing language features.
4+
For stabilizing *library* features, see [Stabilizing a library feature].
5+
6+
[Stabilizing a library feature]: ./stability.md#stabilizing-a-library-feature
7+
38
Once an unstable feature has been well-tested with no outstanding
49
concern, anyone may push for its stabilization. It involves the
510
following steps:

0 commit comments

Comments
 (0)