Rust 1.43 makes command-line binaries easier to find in tests

An integration test for a command-line program needs the executable that Cargo just built. Guessing its location introduces assumptions about output directories and platform naming that Cargo already knows. Rust 1.43 adds an environment variable carrying the absolute executable path when Cargo builds an integration test or benchmark. The test can use that path without reconstructing the build layout.

The release announcement describes a relatively small release, with no major new capability. Its changes are still useful examples of removing accidental difficulty. Tests gain information from the build system, type inference makes better use of context, and macro fragments work in more of the places where their contents belong.

I still tend to choose Go first for command-line tools, but Rust's semantics remain appealing. Improvements like this matter when judging the development experience around those semantics. A tool should provide facts it already owns instead of making each test author derive them again.

The path is available while the test compiles

For a binary target named cli, Cargo sets CARGO_BIN_EXE_cli. The release demonstrates using the compile-time env! macro to obtain its value. This makes the executable location part of compiling the integration test, rather than a convention that the test tries to discover later.

fn executable() -> &'static str {
    env!("CARGO_BIN_EXE_cli")
}

This fragment belongs to an integration test or benchmark in a package with that binary target. It is not a claim that every Rust compilation has such a variable. Cargo supplies it in the build contexts covered by the change.

The Cargo implementation and documentation change computes the path using Cargo's target layout and target-specific executable naming. It adds variables for the package's binary targets when preparing test or benchmark compilation. That places the calculation beside the information needed to make it correct.

The final variable name preserves the binary target name exactly. Earlier work in the pull request uppercased names and changed their spelling, but the accepted revision switches to the target name as written. A binary named my-program therefore uses CARGO_BIN_EXE_my-program. Reading only the initial patch would give the wrong interface.

The documentation also says binary targets build automatically for integration tests or benchmarks, unless their required features are not enabled. A path variable does not override feature requirements. The test still needs a package configuration in which its intended executable is available.

Testing the build-system promise

The Cargo tests exercise binary names with a hyphen and Unicode as well as an ordinary name. They compare the environment values with the expected executable paths. That checks the naming contract directly instead of assuming every target name can be transformed into a conventional shell variable identifier.

The patch also runs the integration-test target through both test and check. The variable must exist during compilation even when the command only checks the test. Otherwise an env! use could fail before any process was launched. This is an example of a build-time interface that needs testing independently of runtime behavior.

Once the path is available, the integration test can concentrate on the command's externally visible behavior. Path discovery no longer needs to become an extra problem inside a test whose purpose is argument handling or output. Cargo remains responsible for the location of its artifact.

Inference uses the expected result

Another change improves inference around primitive values, references, and binary operations. The announcement gives a declaration that fails in Rust 1.42 and succeeds in 1.43.

let number: f32 = 0.0 + &0.0;

The destination type supplies an f32 expectation. Previously, the algorithm instead reached an interpretation involving f64 operands and could not reconcile it with the declared result. The updated inference selects the compatible primitive types. The programmer's explicit result annotation becomes useful information for resolving the expression.

This is a targeted improvement to inference, not permission to mix arbitrary numeric types. The operation still needs compatible operand and result types. The change avoids committing to an inappropriate default before using context that can establish the intended types.

Macro items fit their surrounding declarations

Rust 1.43 permits item fragments to be interpolated into trait bodies, implementation bodies, and extern blocks. A macro accepting an item can place it inside a generated trait, as the announcement's example shows. That removes a mismatch between a captured declaration and a context that can contain that declaration.

The library also gains the primitive module, which reexports primitive types. Macro authors can use it when an ordinary type name might be shadowed. Associated numeric constants become accessible directly through primitive types, including u32::MAX, without importing the corresponding module first.

I see the common benefit in reducing hidden context. Cargo names the executable artifact, inference respects the stated result type, and macro code can identify primitive types explicitly. Each change removes a particular assumption the author previously had to reconstruct or work around while keeping the actual program behavior visible.