Stabilize the rust-version field #9732
Conversation
|
(rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
r? @ehuss |
|
Thanks! Normally the documentation is updated along with the stabilization. Are you intending to add more commits here to stabilize? As for the 2021 stabilization, there still is some risk it could slip a release, since 6 weeks isn't much time. Hopefully it won't, but I assume changing the value shouldn't cause too much of a problem since 2021 is still unstable? |
|
Ah, wasn't sure about the exact wording you used in the tracking issue. I'll add a commit to stabilize. It will be easy to update the first version for 2021 again if necessary. We can do that if/once 1.56 hits beta without 2021. |
|
Add a commit to stabilize. |
|
Stabilizing this seems reasonable to me. @rfcbot merge |
|
Team member @joshtriplett 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
removed
the
proposed-final-comment-period
There was a problem hiding this comment.
arg_ignore_rust_version needs to remove the (unstable) in the help.
--ignore-rust-version needs to be added to the man pages. There is some documentation at https://github.com/rust-lang/cargo/tree/master/src/doc on how to modify those. I would probably put it in the Compilation Options section. There should be plenty of examples of other options on how to share across the man pages.
|
☔ The latest upstream changes (presumably #9751) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Thanks! @bors r+ |
|
📌 Commit c43024f has been approved by |
bors
removed
the
S-waiting-on-review
|
☀️ Test successful - checks-actions |
Update cargo 11 commits in d21c22870e58499d6c31f1bef3bf1255eb021666..cc17afbb0067b1f57d8882640f63b2168d5b7624 2021-07-26 20:23:21 +0000 to 2021-08-02 20:28:08 +0000 - Stabilize the rust-version field (rust-lang/cargo#9732) - Remove nbsp characters. (rust-lang/cargo#9751) - Update unstable documentation TOC. (rust-lang/cargo#9750) - Some minor updates for package/publish package selection. (rust-lang/cargo#9749) - Bump to 0.57.0, update changelog (rust-lang/cargo#9748) - Stabilize `[env]` sections (rust-lang/cargo#9411) - doc: Clarify [doc].browser docs, document PathAndArgs better (rust-lang/cargo#9747) - Bump cargo-util version. (rust-lang/cargo#9745) - Make clippy happy (rust-lang/cargo#9736) - Fix typo in features doc (rust-lang/cargo#9737) - doc test supports silent output (rust-lang/cargo#9730)
Update cargo 11 commits in d21c22870e58499d6c31f1bef3bf1255eb021666..cc17afbb0067b1f57d8882640f63b2168d5b7624 2021-07-26 20:23:21 +0000 to 2021-08-02 20:28:08 +0000 - Stabilize the rust-version field (rust-lang/cargo#9732) - Remove nbsp characters. (rust-lang/cargo#9751) - Update unstable documentation TOC. (rust-lang/cargo#9750) - Some minor updates for package/publish package selection. (rust-lang/cargo#9749) - Bump to 0.57.0, update changelog (rust-lang/cargo#9748) - Stabilize `[env]` sections (rust-lang/cargo#9411) - doc: Clarify [doc].browser docs, document PathAndArgs better (rust-lang/cargo#9747) - Bump cargo-util version. (rust-lang/cargo#9745) - Make clippy happy (rust-lang/cargo#9736) - Fix typo in features doc (rust-lang/cargo#9737) - doc test supports silent output (rust-lang/cargo#9730)
|
Is it just me, or was the FCP cut short for this issue? Shouldn't the FCP have happened in the tracking issue? Very confused about the process now. |
|
We mostly use rfcbot just to get a positive approval from the entire team. We don't broadcast these like the lang team does, and don't usually wait for the comment period. Of course, anyone is welcome to leave comments at any time, and there is 6 to 12 weeks to change or revert any decision. |
rfcbot
added
finished-final-comment-period
This will be stabilized with Rust 1.56, see * rust-lang/rust#65262 * rust-lang/cargo#9732 For older cargo versions, this will print a warning, but will not fail the build/check/test.
374: Specify MSRV in Cargo.toml r=jonasbb a=jonasbb This will be stabilized with Rust 1.56, see * rust-lang/rust#65262 * rust-lang/cargo#9732 For older cargo versions, this will print a warning, but will not fail the build/check/test. Co-authored-by: Jonas Bushart <jonas@bushart.org>
After the rust_version field was stabilized in rust-lang#9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well.
Add rust_metadata to SerializedPackage After the rust_version field was stabilized in #9732 this adds the rust_version as output to the `cargo metadata` command, so tools like Clippy can read and use it as well. We will probably need this for rust-lang/rust-clippy#7765
feat: `lints` feature ### What does this PR try to resolve? Implement rust-lang/rfcs#3389 which shifts a subset of `.cargo/config.toml` functionality to `Cargo.toml` by adding a `[lints]` table. This **should** cover all of the user-facing aspects of the RFC - This doesn't reduce what flags we fingerprint - This will fail if any lint name as `::` in it. What to do in this case was in the RFC discussion but I couldn't find the thread to see what all was involved in that discussion - This does not fail if a `[lints]` table is present or malformed unless nightly with the `lints` feature enabled - The idea is this will act like a `[lints]` table is present in an existing version of rust, ignore it - The intent is to not force an MSRV bump to use it. - When disabled, it will be a warning - When disabled, it will be stripped so we don't publish it Tracking issue for this is #12115. ### How should we test and review this PR? 1. Look at this commit by commit to see it gradually build up 2. Look through the final set of test cases to make sure everything in the RFC is covered I tried to write this in a way that will make it easy to strip out the special handling of this unstable feature, both in code and commit history ### Additional information I'd love to bypass the need for `cargo-features = ["lints"]` so users today can test it on their existing projects but hesitated for now. We can re-evaluate that later. I broke out the `warn_for_feature` as an experiment towards us systemitizing this stabilization approach which we also used with #9732. This works well when we can ignore the new information which isn't too often but sometimes happens. This does involve a subtle change to `profile.rustflags` precedence but its nightly and most likely people won't notice it? The benefit is its in a location more like the rest of the rustflags.
I've tried to make the documentation here fairly comprehensive. I've also updated the first version for the 2021 edition, which should now be stable pending substantial unforeseen changes.
See #8072.