Rust 1.43.1 separates package inspection from publication requirements
Cargo repairs file listing for packages with unpublished dependencies. The release also restores CPU-feature detection that had become incorrectly tied to unstable instruction support.
Listing a package's files should not require that every dependency can already be published. Rust 1.43.0 accidentally imposed that requirement on cargo package --list. A workspace could build locally and still fail a command intended only to inspect its package contents. Rust 1.43.1 restores the distinction between knowing what files belong in an archive and preparing a publishable archive.
The release announcement describes two regressions and an OpenSSL update. The other regression also confused related capabilities. Detecting whether a CPU supports an instruction family does not require stable Rust to expose all of that family's instructions. Both repairs restore a narrower operation that had become entangled with a stronger requirement.
I like Rust's precise semantics, and that precision should extend to its tools. An inspection command should ask for the authority and prerequisites appropriate to inspection. Requiring a publication-ready dependency graph simply to enumerate files adds a constraint unrelated to the user's requested result.
Package contents exist before publication is possible
The reported Cargo regression affected workspaces with path dependencies or unpublished dependency versions. The listing command tried to find registry packages that did not yet exist. That prevented it from returning a file list even though the local source tree contained the information required to enumerate the intended contents.
The Cargo repair moves dependency verification after the listing path returns. It also delays generation of archive-only content. Together these changes allow listing to describe entries without prematurely performing work that requires a publishable dependency graph.
Before the patch, generated-file entries carried their actual contents while Cargo assembled the archive list. Constructing a generated manifest or lockfile could therefore trigger publication-oriented work during enumeration. The new representation records what kind of generated file the entry needs. It distinguishes a generated manifest, a lockfile, and version-control information.
The archive-writing phase then generates the appropriate contents when needed. This separates the name of an entry from the work required to materialize it. A listing can include Cargo.lock without first resolving every dependency as if the command were creating the final archive for upload.
That is a specific form of deferred work. It preserves the intended list while avoiding unnecessary preconditions on that list. It does not promise that every listed package will successfully archive or publish afterward.
The regression test preserves both outcomes
The patch adds a package with a versionless path dependency. Its listing succeeds and includes the expected manifest and source entries. Running the actual packaging operation still fails because path dependencies need specified versions for packaging. The test deliberately checks both results.
That pair matters. Repairing listing by removing publication checks from every path would make a different mistake. Cargo still needs to reject an archive whose dependency information cannot meet packaging requirements. The correction changes when the checks apply, rather than weakening their purpose.
An ordinary invocation remains short.
cargo package --list
The command asks for the contents, not for successful publication. Build and release automation can use that answer during intermediate stages, while dependencies remain local or unpublished. The package-writing path retains its own stronger validation.
Detecting a CPU capability does not expose its instructions
The release also restores detection of x86 capabilities that stable Rust cannot yet use directly, including AVX-512 families. An internal refactoring in 1.43.0 prevented previously permitted is_x86_feature_detected! queries. The original regression report shows an unstable-library diagnostic arising from a feature-detection invocation.
The macro's question concerns the executing machine. Availability of a stable intrinsic is a question about Rust's public library API. Combining the two restrictions prevents a program from learning a hardware fact even when it does not invoke the corresponding intrinsic through unstable Rust APIs.
Restoring detection therefore does not stabilize every associated instruction interface. Code still needs to respect the availability and safety requirements of whatever implementation it chooses. The patch returns the detection operation to the behavior available before the refactoring.
I regard the two regressions as useful examples of why compatibility includes tooling behavior. A project can depend on a file list or hardware query without depending on the stronger operation next to it. Preserving that narrower use prevents unrelated changes from blocking otherwise valid workflows.
Cargo's OpenSSL dependency also changes
Rust 1.43.1 updates the OpenSSL version used by Cargo to 1.1.1g. The release team says the upstream security fix did not arrive in time for 1.43.0. It also explicitly reports no evidence that the vulnerability could compromise Cargo users.
Those statements should remain separate. Updating a dependency after an advisory is concrete maintenance work. It does not establish that Cargo users experienced an exploit, or that every build of an application inherits Cargo's own OpenSSL dependency. The announced update concerns the tool.
The release repairs the package-listing and feature-detection behaviors while keeping their surrounding requirements distinct. Enumeration can proceed before publication is possible, and CPU detection can report a capability before Rust exposes its instructions on stable. Each corrected operation again answers the narrower question its caller asked.