Skip to content
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.

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

Add support for preview features #9401

Closed
wants to merge 2 commits into from

Conversation

jonhoo
Copy link
Contributor

@jonhoo jonhoo commented Apr 23, 2021

This is an experimental implementation of a feature that adds preview
features
to Cargo. A preview feature is one that is still considered
unstable, but is available on stable/beta for testing behind a new flag,
--enable-preview that requires you explicitly enumerate the features
to enable.

The core idea is that the Cargo team would specifically designate
a small set (potentially zero at any given point in time) of features as
"available for preview", subject to criteria that ensure that a preview
period of a feature is both worthwile and won't cause undue breakage. A
rough framework for how to think of these was proposed in
https://internals.rust-lang.org/t/survey-of-high-impact-features/14536.

This implementation exists mainly to get feedback on whether the
approach taken here is reasonable from a code point-of-view. Before this
feature lands (if it does), it would have to go through an RFC process.

For the initial implementation, I have designated one unstable feature
(patch-in-config) and one unstable option (--out-dir) as "preview".
This choice was based on some of the internals discussion linked above,
but is in no way final.

This is an experimental implementation of a feature that adds _preview
features_ to Cargo. A preview feature is one that is still considered
unstable, but is available on stable/beta for testing behind a new flag,
`--enable-preview` that requires you explicitly enumerate the features
to enable.

The core idea is that the Cargo team would specifically designate
a small set (potentially zero at any given point in time) of features as
"available for preview", subject to criteria that ensure that a preview
period of a feature is both worthwile and won't cause undue breakage. A
rough framework for how to think of these was proposed in
https://internals.rust-lang.org/t/survey-of-high-impact-features/14536.

This implementation exists mainly to get feedback on whether the
approach taken here is reasonable from a code point-of-view. Before this
feature lands (if it does), it would have to go through an RFC process.

For the initial implementation, I have designated one unstable feature
(`patch-in-config`) and one unstable option (`--out-dir`) as "preview".
This choice was based on some of the internals discussion linked above,
but is in no way final.
@rust-highfive
Copy link

r? @Eh2406

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 23, 2021
@bors
Copy link
Contributor

bors commented May 5, 2021

☔ The latest upstream changes (presumably #9457) made this pull request unmergeable. Please resolve the merge conflicts.

@jonhoo
Copy link
Contributor Author

jonhoo commented May 12, 2021

I'm going to go ahead and close this given the closure of rust-lang/rfcs#3120.

@jonhoo jonhoo closed this May 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants