Cargo check separates compiler feedback from a runnable build
Rust 1.16 adds a command for checking code without producing the final executable. Metadata-only dependencies support the shorter path, while execution tests still answer a different question.
A developer can invoke a build without intending to run its output. During an edit, the immediate question may be whether the new code satisfies the compiler. Generating machine code for a disposable executable adds waiting after that question has already been answered. Rust 1.16 introduces cargo check for this stage of development.
The March 16 announcement describes the command as running the compiler checks without producing the final binary. The versioned release notes identify the compiler support underneath it, --emit=metadata and the .rmeta file format. This is an alternate compilation result designed for feedback, not a cached executable or a new way to run tests.
I find the static checks in Rust valuable precisely because they answer questions before execution. That makes the time needed to obtain those answers part of the language experience. A dedicated checking command lets the workflow ask for the result it currently needs without paying for a final binary on every edit.
Code generation has a separate cost
The announcement divides compilation into a checking phase and a phase that produces executable code. It notes that the latter can consume substantial time. A normal build performs both because its purpose includes making a program available to execute. A developer checking a partial edit may need only the first result.
The new command gives that intention a standard spelling. It avoids requiring an editor integration or a developer script to invent a reduced compilation path independently. Cargo remains responsible for the project and dependency relationships, while the compiler supplies the metadata-only output required to check them.
cargo check
This command belongs where the next decision depends on compiler acceptance. A successful check means the code has passed that checking path. It does not mean a test has exercised the program, because the command has not produced and run the final executable.
That distinction is useful for organizing feedback. A type error should be found before waiting for a test run that cannot begin. A behavioral error requires observations that type checking does not provide. The shorter command makes the first step cheaper without changing the purpose of the second.
Dependencies need information even without code
Checking one crate requires information about the crates it uses. Omitting final machine code cannot mean omitting their public types or other compilation metadata. The .rmeta output supplies metadata about a crate without a complete executable-code result.
The versioned release notes say rustc --emit=metadata produces this new kind of file. The announcement explicitly connects it to cargo check dependencies. Cargo can arrange the dependency checks while rustc reads the information needed to understand the program being checked.
The announcement also identifies the Rust Language Server as a potential consumer. That follows from the same separation. An editor needs semantic information for feedback about code, even when no user has asked it to create a runnable program. A compiler output intended for that information gives tools a more direct input than a complete build artifact.
This is a change in the tool interface as well as a performance optimization. A build system can request a named output with an appropriate purpose. It need not rely on the accidental side effects of compiling all the way to a binary merely to obtain information for analysis.
The reported gains vary by project
The release post includes timings for three projects and explicitly calls the comparison unscientific. Its initial runs start from a newly cloned project. Its secondary runs add a blank line to the top of a source file and invoke the command again. Those conditions are part of interpreting the figures.
For the Cargo project in that comparison, an initial build takes 236.78 seconds and an initial check takes 148.52 seconds. The secondary comparison is 64.34 seconds against 9.29 seconds. For Diesel, the difference is much smaller, with an initial build of 15.27 seconds against a 12.81-second check.
The variation supports a mechanistic interpretation. The command saves work that a particular build would otherwise spend producing code. Its benefit depends on how much of that work exists in the project and its dependencies. A single multiplier would erase the difference that the published examples actually show.
The secondary Cargo result is especially relevant to repeated editing, but it is still one described experiment. It does not establish the speed of every future edit or every machine. The useful general fact is which stage the command omits, with the measurements illustrating how large that stage can be in some projects.
Cargo also adds workspace-wide flags to build and documentation commands in this release. These changes keep related packages accessible through the ordinary project tool rather than requiring repeated manual invocations for each member.
Better feedback can also mean fewer suggestions
The release removes an inaccurate lifetime suggestion that previously asked users to add an explicit parameter. The announcement walks through a FromStr implementation trying to return a borrowed value. Following the suggestion leads to another incompatible signature, followed by further advice that fails to solve the underlying problem.
The project chose to remove that help message until it could constrain the false positives. This is relevant to the same feedback loop. A quicker diagnostic that directs a newcomer toward impossible changes does not make development more effective. Feedback quality includes whether a proposed repair respects the trait contract.
The announcement also describes broader typo suggestions and a more specific error for slicing a string inside a multibyte character. These are different improvements from avoiding code generation. They improve the information available when the checking or execution path finds an error.
I prefer this combination of shorter waiting and more accurate explanations. The command makes static feedback easier to obtain, while the diagnostic changes address what a programmer can usefully do with it. Tests still need a build and an execution path to establish behavior, and cargo check now supplies a distinct command for the earlier question about compiler acceptance.