You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/future-proofing.md
+5-3Lines changed: 5 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -209,12 +209,14 @@ on the data structure.
209
209
Some libraries need to use, or want to experiment with, the [nightly channel].
210
210
To avoid accidental breakage, libraries should either:
211
211
- Use nightly features unconditionally, so that people depending on the library must always use a nightly toolchain to build
212
-
- Add a cargo feature which opts-in to the nightly features (optionally, with feature detection to verify the features are present in the current compiler version). This allows people to avoid opting-in if they do not want to be exposed to possible breakage.
212
+
- Add a `--cfg` flag which opts-in to the nightly features (optionally, with feature detection to verify the features are present in the current compiler version). This allows people to avoid opting-in if they do not want to be exposed to possible breakage.
213
213
214
-
Each nightly feature should be under a separate cargo feature so that breakage to one feature does not cause breakage for others.
215
-
For example, if you depend on two different nightly features, `std::intrinsics::black_box` and `std::intrinsics::catch_unwind`, create two cargo features named `nightly-black-box` and `nightly-catch-unwind`.
214
+
Each nightly feature should be under a separate flag so that breakage to one feature does not cause breakage for others.
215
+
Each flag should be prefixed with the crate name to avoid accidentally triggering features in other crates.
216
+
For example, if your crate is named `awesome-lib` and depends on two different nightly features, `std::intrinsics::black_box` and `std::intrinsics::catch_unwind`, create two cfgs named `awesome_lib_black_box` and `awesome_lib_catch_unwind`.
216
217
217
218
When doing feature detection, we recommend *against* simply checking whether the compiler is a nightly channel, as nightly features frequently change between compiler versions.
218
219
Feature detection should compile a sample rust program and verify that it works.
220
+
Note that flags like `-Z allow-features` may affect whether features are allowed.
0 commit comments