Rust 1.93.1 repairs tooling and WASI resource cleanup
The patch fixes parser recovery used by rustfmt, a Clippy false positive, and leaked file descriptors on wasm32-wasip2. Each regression came from a different interaction within the toolchain distribution.
Dropping a Rust file value should release its resource, but a dependency update in the Rust 1.93 distribution broke that behavior for wasm32-wasip2. The Rust 1.93.1 announcement, published on February 12, fixes that regression by reverting the update. The same patch also repairs a parser crash affecting rustfmt and a Clippy warning that misunderstood mutation through an implicit dereference.
This is a small release with three distinct failure mechanisms. Its details matter more than the size of the version increment. A formatter crash interrupts source maintenance, a false lint can block a clean build, and a missing resource release affects a running component. They require different explanations even though one toolchain update distributes all the corrections.
The WASI fix restores a consistent dependency combination
The revert pull request explains that the rustup-distributed WASI artifacts move back from wasi-sdk 29 to 27. The newer dependency included substantial wasi-libc changes toward using WASIp2 interfaces directly. Rust's standard library was using a mixture of wasi-libc and direct WASIp1 behavior. That combination produced the resource-cleanup defect.
The practical consequence was that dropping std::fs::File failed to release its descriptor, allowing components to exhaust their descriptor limit. The patch restores the earlier bundled dependency combination. It does not require application authors to add manual cleanup around every file value, which would obscure the ownership semantics the standard library is supposed to implement.
The release announcement limits the packaging claim to the rustup component for the target. Downstream toolchain builders need to inspect their own dependencies. A distribution version does not fully identify the affected native dependency combination when another distributor builds the artifacts differently.
This is one reason I find Rust's ownership model compelling while still treating its platform implementation as part of the system. The language describes when a value's destructor runs. The destructor must then reach the correct platform operation. A sound ownership pattern in application source cannot repair an inconsistent resource implementation underneath it.
Parser recovery must be allowed to stop
The parser correction concerns recovery from invalid syntax in a macro invocation. The reported case passes the keyword Self where recovery tries to parse a non-keyword identifier. That attempt fails, and the recovery path itself produced an internal compiler error. The patch stops trying that recovery when the token is a keyword.
This is different from rejecting a program for invalid syntax. The compiler is allowed to diagnose an invalid fragment, but its diagnostic machinery must not assume that an attempted interpretation succeeds. Recovery adds speculative paths through the parser. Those paths need ordinary failure handling even though their purpose is to improve the explanation of another failure.
The rustfmt report shows the practical reach of that shared parser code. A cargo fmt invocation panicked inside rustc_parse while processing the keyword case. The formatter therefore exposed a compiler parser defect through an operation that users may not think of as compilation. Toolchain components share enough implementation that a parser regression can interrupt a formatting workflow.
The fix preserves a sensible limit on diagnostics. When recovery has no coherent interpretation, declining to recover is better than constructing another failure. That is a technical choice about which parser states the implementation can support, rather than a new restriction on valid Rust programs.
Clippy must account for a field being changed
The Clippy fix repairs a panicking_unwrap false positive involving a field reached through an implicit dereference. Its regression test checks an optional field, assigns Some(10) inside the branch, and then unwraps that field. The earlier condition does not describe the field after the assignment.
The patch changes how the analysis compares field projections. It filters the projections to fields before comparing their indices with the recorded field path. This makes the analysis account for the relevant mutation even when implicit dereferencing contributes other projections to the representation.
That mechanism explains why rewriting a valid program to avoid a warning can be the wrong response. The warning depends on a stale inference about the value after mutation. The test gives the lint a concrete sequence in which its conclusion must change. Application semantics should not be distorted to satisfy an analysis that has lost track of the assignment.
Rust's tooling is part of what makes its detailed semantics usable to me. Useful diagnostics reduce the amount of reasoning a programmer must repeat manually. Their reliability depends on distinguishing a real defect from a valid state change, and this correction restores that distinction for a specific field-access pattern.
The patch release consequently has different deployment implications for different users. Formatting and linting users receive corrected development tools. Users distributing wasm32-wasip2 components need artifacts built against the corrected target component, while downstream toolchain distributors must establish which WASI dependencies they actually ship.