Add -Zallow-features to match rustc's -Z #9283
Conversation
|
r? @Eh2406 (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@jonhoo I just wanted to double check, I didn't follow the discussion on internals too closely. Is this still the direction you want to go? |
|
Yes, I think this feature is going to be part of the eventual solution at least. I think I'd also want a way to enable this through an environment variable, but that's sort of secondary. For now, this is a way to get feature-parity with |
|
85f7c80 makes it so that |
There was a problem hiding this comment.
I think it might be worthwhile to add this to the fingerprint? If, for example, you build a project, and then remove a feature from allow-features, and then build again to see what breaks, nothing happens. The fingerprint code is in fingerprint.rs, and you can search for rustdoc_map for an example. It just needs to add the hash to the config value.
One downside is that it will rebuild everything, so I'm uncertain if that is worth it. WDYT?
If this weren't the case, a user that compiled, and then re-ran cargo with a particular set of allowed features would not see any breakage even if other unstable features were used. The downside of this is that changing allow-features causes a full re-compile, but that still _seems_ like the right thing to do.
|
Err, I'm not sure what's causing the CI error — it seems unrelated to this change? |
|
Team member @ehuss has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
the
final-comment-period
rfcbot
removed
the
proposed-final-comment-period
|
@bors: r=ehuss |
|
📌 Commit 8d79a75 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Update cargo 3 commits in 3c44c3c4b7900b8b13c85ead25ccaa8abb7d8989..65d57e6f384c2317f76626eac116f683e2b63665 2021-03-31 21:21:15 +0000 to 2021-04-04 15:07:52 +0000 - Fix typo in contrib docs. (rust-lang/cargo#9328) - fix clippy warnings (rust-lang/cargo#9323) - Add -Zallow-features to match rustc's -Z (rust-lang/cargo#9283)
Update cargo 3 commits in 3c44c3c4b7900b8b13c85ead25ccaa8abb7d8989..65d57e6f384c2317f76626eac116f683e2b63665 2021-03-31 21:21:15 +0000 to 2021-04-04 15:07:52 +0000 - Fix typo in contrib docs. (rust-lang/cargo#9328) - fix clippy warnings (rust-lang/cargo#9323) - Add -Zallow-features to match rustc's -Z (rust-lang/cargo#9283)
rfcbot
added
finished-final-comment-period
This PR implements the
-Zallow-featurespermanently-unstable feature flag that explicitly enumerates which unstable features are allowed (assuming unstable features are permitted in the first place). This mirrors the-Zallow-featuresflag ofrustcwhich serves the same purpose forrustcfeatures:https://github.com/rust-lang/rust/blob/5fe790e3c40710ecb95ddaadb98b59a3bb4f8326/compiler/rustc_session/src/options.rs#L856-L857
This flag makes it easier to beta-test unstable features "safely" by ensuring that only a single unstable feature is used if you only have control over build system, and not the source code that developers may end up using, as discussed in this internals thread.