Rust & AI Weekly #17: test the value across the FFI boundary

Check the value where another component receives it. Original 3D editorial illustration, not a technical diagram or measured result.

A C caller passed 0x10 into a Rust function that returned a bool. The expression tested the lowest bit, so the expected result was false. With Rust 1.99.0 on x86_64 Linux, the reporter observed 16. The source expression looked ordinary; the generated return sequence was missing a mask present in 1.98.0.

The regression report includes both languages and the assembly. Rust 1.99.1, released October 15, restores the required zero-extension for FFI boolean returns on x86_64. If you ship a Rust library to another language, include that caller in the upgrade check. A test confined to Rust leaves the reported boundary unexercised.

This edition evaluates that compiler patch and three development tools: Creusot's verification conditions, hotcode's runtime reloads, and hotpath's profiling context. They address different jobs. The proposed checks below are review plans; I have not run these tools or reproduced the reported compiler bug in this review.

Sources checked October 19, 2026. Scan window: October 12–19. Older releases are identified where a new article or unresolved question brought them back into view. No benchmark was independently reproduced.

Two additions and one returning crate evaluation. The radar contains 92 tools: 15 Adopt, 36 Trial, 39 Assess and 2 Hold. The compiler patch is discussed separately from the crate inventory. Explore the radar.

Rust 1.99.1: upgrade, then run the foreign caller

Adopt the patch for an existing 1.99 toolchain, with your normal release checks. The release announcement identifies three regressions: the FFI return bug, missing wcslen on some targets, and macOS rust-lld failing to locate libLLVM when invoked outside the rustup proxy path.

The boolean report reproduced with both GCC and Clang callers on x86_64 Linux. Its author did not reproduce the same behaviour on aarch64 or loongarch64, where the value was masked before returning. Those observations bound the report. They do not establish that every FFI function was affected, or that a particular application suffered corrupted results.

For a library with a C interface, I would retain a small test in which the external executable calls the exported function and checks the result. Build it with the compiler and flags used by the actual consumer. Keep the Rust compiler version, C compiler and target in the test output so a later failure can be compared with a specific build.

Choose inputs that distinguish the intended result from an unnormalised register value. The report's 0x10 case does that for a low-bit test. Add the corresponding true case if your interface has one. Checking the result at the caller also avoids relying on a test wrapper that accidentally changes the generated calling sequence and hides the original failure.

Rebuild the artifact the other language loads

A compiler upgrade changes future builds. It does not replace a library already copied into an application bundle, container or package. In an upgrade review, identify the shared or static library that the consumer actually uses, rebuild it, and run the consumer against that output. Record its path or package identity alongside the compiler version.

For the other fixes, choose the affected invocation. The wcslen issue involved an LLVM optimisation introducing calls unavailable on some targets; UEFI programs using std were specifically affected. The macOS linker fix concerns library discovery outside the rustup proxy. A build through a different wrapper may never exercise that failure path.

• Maintenance: Rust Release Team point release, with linked regression reports.
• Latest release checked: stable Rust 1.99.1, announced October 15.
• Adoption signal: an official supported compiler release; no independent rollout result from this review.
• Scope: this verdict recommends the corrective patch for existing users. It does not recommend raising every library's minimum supported Rust version.

For an AI-generated binding change, ask the reviewer to follow one value across the interface. Check the generated declaration, argument representation and returned value from the consumer's side. The compiler regression gives a concrete reason to keep that test even when the Rust expression itself has not changed.

Creusot 0.14.0: review the specification as code

Assess. Creusot 0.14.0 was published October 12; its explanatory devlog followed October 13. It verifies properties stated in contracts by translating Rust into a verification language and using Why3 and provers. The project's own changelog still calls the software experimental and describes data structures and algorithms as a better fit than systems dominated by external interactions.

That makes a contained algorithm a useful starting point for a team reviewing generated Rust. Pick a function with a property you can state precisely: a bounded counter, a search result that refers to a matching element, or a transformation that preserves a specified relation. Keep the claimed property visible next to the implementation before asking a prover to establish it.

The 0.14 devlog describes new verification conditions for logic calls inside snapshots. A lemma's precondition is asserted at the call, and its postcondition becomes available for the particular argument. That enables proof steps without introducing an ordinary runtime call. The authors also describe catching specification mistakes earlier, including invalid indexing in specification expressions.

This is useful when the contract itself came from an agent. A successful proof establishes the stated proposition under its assumptions; the review still needs to establish that the proposition expresses the requirement. If a contract silently excludes an empty input that the API accepts, a proof for the remaining inputs leaves that API case unanswered.

Keep a deliberately wrong variant

I would keep one small implementation mutation that violates the intended property, then confirm that the verification job rejects it. Separately, weaken or remove the relevant contract in a disposable copy and inspect what the tool can still prove. These are proposed checks of the project's verification setup, not evidence that Creusot currently misses a particular defect.

The exercise gives the reviewer something more concrete than a green command. It connects one requirement to one contract and one failure the job must catch. Save the exact source revision and toolchain with the result. A proof log without the inputs that produced it is difficult to review after either the generated implementation or its annotations change.

The tagged changelog also records PermCell becoming PCell, an opaque authentication fragment, and improvements to specifications for slices and conversions. Treat those as migration inputs for an existing proof project. The partial-order discussion in the devlog describes a change introduced in 0.13; it is not all new in 0.14.

Editor support now includes more precise go-to-definition inside Pearlite specifications. It requires the documented rust-analyzer configuration so specification macros expand appropriately. I would check navigation on an actual contract expression before assuming that ordinary Rust editor settings provide the same view of the proof code.

• Maintenance: public Creusot project, versioned changelog, examples and installation guide.
• Latest release checked: non-prerelease GitHub tag 0.14.0, October 12 at 08:49:08 UTC. Its toolchain file pins nightly-2026-08-03.
• Adoption signal: the tagged README names CreuSAT and Krabka as projects using Creusot. That is project-reported usage, not independent validation of this release.
• Licence: the root licence and creusot-std metadata identify LGPL terms; creusot-std specifies LGPL-2.1-or-later. Review component and distribution obligations before a commercial integration. This is not an MIT-only toolchain.

Assess reflects the experimental tooling, proof-maintenance cost and need to review the contract. I would trial one isolated algorithm before assigning a service-wide verification project. Keep the existing runtime tests for the surrounding interfaces, including foreign callers and external state that the selected proof does not model.

hotcode 1.0.3: keep reloads inside a controlled development loop

Assess for development use. hotcode reloads annotated Rust functions from a rebuilt dynamic library. Its 1.0.3 package was published October 17, after the project appeared as This Week in Rust's October 14 Crate of the Week. The source manifest requires Rust 1.89.0 and supports a library configured with both dylib and rlib outputs.

That can shorten the loop for a long-lived development process whose useful state is expensive to reconstruct. It also introduces a boundary between the code still running and the library just loaded. The crate documentation explicitly lists ABI changes and retained static references among its limitations. Generic functions are unsupported.

The documentation gives an example of a caller that still passes a string while the reloaded callee now expects an integer slice. Rebuilding a source file does not rewrite a caller already executing in the process. It also warns that a static reference returned by an old library can dangle after that library unloads. The attribute does not make these edits safe.

Decide which edits require a restart

For a first evaluation, choose a function with owned inputs and outputs and keep its signature fixed. Change only its implementation, rebuild, and confirm that the running process observes the new behaviour. Then restart normally and compare the result. Record a clear restart rule for signature, layout or lifetime changes before other developers use the workflow.

A reload result can otherwise be misleading during an agent-driven edit session. An agent may update a type and its call sites together in the source tree, while the running process still contains an older caller. The review should distinguish a successful compilation of the new sources from compatibility with the process that remains alive.

The documented implementation keeps a cloned library handle alive for each invocation, preventing unloading while that invocation uses it. That protects a running call. It does not extend the lifetime of a reference the call returned into an old library. Keep that distinction in the development guidance instead of summarising the mechanism as safe hot reload.

By default, reload behaviour is enabled with debug_assertions. The always argument enables it for release builds too. Check the actual build configuration rather than assuming that a release profile alone determines the behaviour. For a development trial, I would leave the default and inspect the release artifact separately before shipping the dependency.

• Maintenance: public project maintained by Aleksei Orazov; source reviewed at commit d125836c7ea80d6ee70067675e8c0a49aa6d3bd0, dated October 17.
• Latest release checked: crates.io 1.0.3, October 17 at 12:13:39 UTC; not yanked. No GitHub release or tag was returned by the checked endpoints.
• Adoption signal: repository examples and the community spotlight. No independent production deployment established.
• Licence: MIT, with the copyright and permission notice retained when redistributing. Dependency notices remain a separate check.

The documentation includes Fibonacci microbenchmarks on named Intel CPUs and an Apple M4. I have not reproduced them and use no timing claim here. The initial decision is whether the reload constraints fit your development workflow; performance measurement comes after the allowed edit surface is clear.

hotpath 0.28.6: give the measurements a denominator

Trial, retained. Paweł Urbanek's October 12 Grafana tutorial gives hotpath a fresh evaluation point. The latest checked crate remains 0.28.6, published October 8. The article's example output shows 0.28.3; that example is not evidence of a newer release or a measurement of every subsequent patch.

The tutorial correlates SQL calls, outbound HTTP work and instrumented function measurements with an Axum route. That is useful for a service where one request can trigger a variable amount of work. A fast individual query can still be a problem if a request repeats it for every returned row. Compare query counts with the number of requests that produced them.

For an agent endpoint, I would select one bounded operation and record the input size, completed requests, outbound calls and failures. Replay the same input set before comparing two implementations. If one version returns fewer successful results, lower total processing time may describe less completed work rather than an optimisation.

Preserve the accounting rules in the dashboard

The tutorial distinguishes inclusive function time from exclusive allocation accounting. Adding nested inclusive durations can count the same interval more than once. Its cumulative allocation option can likewise count recursive work repeatedly. Label those views so someone reviewing a generated dashboard knows what may be summed and what must be read separately.

Its lock examples also separate waiting to acquire a lock from holding it. I would inspect both against a fixed workload before moving work out of a critical section. Keep the before-and-after request result in the fixture: a shorter hold time is useful only if the revised operation still produces the intended state.

The tagged package manifest makes Prometheus export a feature, not an automatic consequence of adding the dependency. The tutorial also notes that some Tokio worker metrics require --cfg tokio_unstable. Record the chosen features and flags with the dashboard so an absent series is not mistaken for a zero measurement.

I would begin with a local or restricted metrics endpoint and inspect the labels before enabling a shared scraper. Check that route labels describe the intended route grouping and that no sensitive request content enters the exported dimensions. This is a proposed deployment check; this review does not claim to have audited every emitted label or endpoint configuration.

• Maintenance: actively developed Paweł Urbanek project, with tagged source and a new integration tutorial.
• Latest release checked: 0.28.6; GitHub release October 8 at 21:48:44 UTC, registry publication at 21:57:36 UTC. Package metadata provides no MSRV, so none is inferred from the edition.
• Adoption signal: the author describes profiling the tool and its own backend. The tutorial says that backend serves minimal traffic; its results do not establish overhead for a busier service.
• Licence: tagged MIT licence. Cloud service use has a separate operational context from the local crate.

The release links a moving changelog, while the tagged changelog begins at 0.28.5. I have not assigned an unverified patch-specific feature to 0.28.6. Trial remains conditional on a representative overhead comparison, useful attribution and a deployment configuration your team can inspect.

Toolchain and ecosystem notes

The Rust Infrastructure Team's Q3 recap separates deployed work from provisioned infrastructure. It reports GitHub Actions audits running through crabwatch, with 23 Zizmor audits enabled by default. It also describes an SQS FIFO queue between crates.io and docs.rs that was provisioned but still unused when the report was written.

For a team adopting automated review, that is a useful status distinction to copy into its own release notes. Record whether a check ran on the reviewed revision and whether failure blocks delivery. Installing an auditing workflow is different from proving that an affected change was rejected by it. The recap does not establish the enforcement settings in your repositories.

The Rust Foundation board update announces Jana Dönszelmann and Nia Deckers as newly elected Project Directors, and Jess Wass as Meta's representative. Those are governance changes, not evidence for a dependency verdict. They belong in the reading list without being made into an engineering trend.

Reading list and open checks

• This Week in Rust 673 supplies the community index, including Bevy 0.20 and Yagi Signal Lab. The Bevy announcement is dated October 8; appearance in this roundup does not make it an October 14 release.
• Rust Bytes 141, October 13, covers the developer survey, glam and further links. Survey rankings and the linked benchmark claims were not independently verified for this issue, so no adoption or performance verdict relies on them.
• Go Weekly 620 remains the latest issue returned by its archive. It explicitly announced an October 16 break and an October 23 return. Its HTTP-body ownership investigation was covered in issue #16; no new Go edition is invented here.

The rmcp release endpoint still returned 3.5.1 as the latest runtime release in this scan. Its transport and credential-store trial checks remain open. Workers, Deser, Ying, Wild, allocator stabilization and tokio_rcu also keep their earlier verdicts and unresolved checks. No fresh execution or version-specific adoption evidence was established here to upgrade them.

If you maintain a Rust library called from C, Python or another language, pick one exported boolean result and run the real consumer against the rebuilt library. Reply with the target, compiler versions and whether that caller is part of your release checks. Keep credentials and private application data out of the example.