[stable-1.69] Add the Win32_System_Console feature since it is used

[lu-zero]

In src/cargo/core/shell.rs windows_sys::Win32::System::Console is used but the feature is not present in Cargo.toml.

I found it while updating cargo-c. (now for the 1.69.0 branch)

[rustbot]

r? @epage

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

⚠️ Warning ⚠️

• Pull requests are usually filed against the master branch for this repo, but this one is against rust-1.69.0. Please double check that you specified the right target!

[epage]

As a heads up, as this is a backport into the rust-1.69.0 branch, that implies that we'd be doing a patch release of rust for this. Could you expand on why that is needed? By appearance, this should only be needed for cargo-as-a-library and this problem can easily be worked around in the dependent crate by requiring the feature.

[lu-zero]

I fixed the issue in cargo-c this way, here how it present itself.

I prepared it in case we want a point release.

[epage]

For reference, #12016 fixes this in master

[ehuss]

@rfcbot fcp merge

@rust-lang/cargo I think it would be good to backport this to both stable and beta. The current 0.70.0 release of the library doesn't build on Windows due to a missing feature.

This PR will also need to bump the patch version in Cargo.toml, and also backport #12011 to get CI to pass. We can then publish the new version to crates.io (no need for a stable release of Rust itself). I can handle those after this FCP passes.

The reason this happened is because cargo-util in tree includes the feature, but the version number of cargo-util was never bumped after it was changed, so the version of cargo-util on crates.io is outdated.

@weihanglo Part of the release process (documented here) is to check if any of the in-tree crate versions need to be bumped. It seems like this process broke down. Is there some way we can improve the process to make sure this doesn't happen in the future?

Also, does anyone have any ideas on how to catch this in CI? I'm thinking of perhaps some way to check if cargo-the-library can be built, but that inherently needs its dependencies to be "published", which is the very reason this failed, so I'm not sure offhand how best to do that.

[rfcbot]

Team member @ehuss has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

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.

[weihanglo]

Part of the release process (documented here) is to check if any of the in-tree crate versions need to be bumped. It seems like this process broke down. Is there some way we can improve the process to make sure this doesn't happen in the future

A simple proposal: In CI, use git diff to compare latest version and current local If there are some changes, fail the CI and require at least a version bump. Also, we can leverage cargo-semver-checks to ensure the semver compatibility.

[epage]

A simple proposal: In CI, use git diff to compare latest version and current local If there are some changes, fail the CI and require at least a version bump. Also, we can leverage cargo-semver-checks to ensure the semver compatibility.

I recommend we evaluate the use of cargo release.

1. When releasing a crate, it will warn you if you leaving out a crate
2. cargo release changes will show all commits for each crate, highlighting conventional commit fields of interest

These both require tags to be associated with the crates, though you can share tags across crates. It knows which commits are for a crate by using cargo package --list.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[ehuss]

I opened #12033 to continue the discussion of how to deal with versioning. Feel free to leave ideas over there on how we can better manage them.

[ehuss]

@bors r+

[bors]

📌 Commit 8cdc12c has been approved by ehuss

It is now in the queue for this repository.

[bors]

⌛ Testing commit 8cdc12c with merge d71aa2e...

[bors]

☀️ Test successful - checks-actions
Approved by: ehuss
Pushing d71aa2e to rust-1.69.0...