Creusot Devlog

Creusot 0.10.0: February update

2026-02-24T00:00:00+00:00

What's new in Creusot?</h2>
This February's release brings a couple of QOL improvements. For the rest, see the Changelog</a>.</p>

The proof_assert!</code> macro now supports the #[trusted]</code> attribute.</p>

#</span>[</span>trusted</span>]</span></span>
proof_assert!</span> {</span> answer</span> ==</span> 42</span> };</span></span></code></pre>
It removes the proof obligation that would come from the assertion,
so it effectively becomes an assumption</em> available to
the rest of the program after it.</p>
We could have called it assume!</code> or proof_assume!</code>,
but reusing #[trusted]</code> makes it convenient to grep for all
assumptions in a project.</p>
This is useful as a placeholder à la todo!()</code>, letting you
stub out parts of a proof while you're focusing on other aspects
of it.</p>
Wildcard patterns on integers</h3>
In match</code> expressions with integer patterns,
the wildcard branch now remembers the values that
the integer does not</strong> equal.</p>
match</span> n</span> {</span></span>
    42</span> =></span> proof_assert!</span> {</span> n</span> ==</span> 42</span> },</span></span>
    _</span> =></span> proof_assert!</span> {</span> n</span> !=</span> 42</span> },</span> // FIXED</span></span>
}</span></span></code></pre>
Thanks to Eric Jackson for the contribution</a>!</p>
Multi-package workspaces</h3>
We added options to select packages in workspaces.</p>
The command line option -p</code> (or --package</code>) selects a package to build
with cargo creusot</code> and to run provers on with cargo creusot prove</code>.
This is basically the same option as in cargo build</code>, but to call why3find</code>
and run provers, we must additionally find the output Coma files corresponding
to these packages.</p>
As the Creusot compiler is basically a modified rustc</code>, the unit of compilation is a crate.
A package defines multiple crates, and cargo</code> does not build all of them by default:
only libraries and binaries, excluding tests, examples, and benches.
Creusot only supports that default target selection for now (that is libraries and binaries),
until the need for others arises.</p>
You can also choose a default set of packages to build with cargo creusot</code>,
using the default-member</code> field in the [workspace.metadata.creusot]</code>
section of your workspace Cargo.toml</code>:</p>
[</span>workspace.metadata.creusot</span>]</span></span>
default-members</span> =</span> [</span>"PKG1"</span>,</span> "PKG2"</span>]</span></span></code></pre>
This falls back to the existing default-member</code> field in [workspace]</code>
for regular cargo build</code>. Having a separate field for Creusot lets you
designate packages specifically as targets for formal verification,
next to other buildable but unverified packages.</p>
Story of a toolchain update</h3>
Creusot depends on a nightly Rust toolchain. With this release,
we upgraded our toolchain from nightly-2025-11-13 to nightly-2026-01-29.</p>
We do toolchain upgrades regularly to keep up with the fast-moving
rustc</code> API. Ideally we do this at the beginning of each release cycle
to give time to potentially subtle issues to surface by the next release.</p>
This time, there was one change that required a bit of thinking to deal with:
the orphan check now panics when it encounters an unnameable type
(typically, a function type).</p>
The orphan check and unnameable types</h4>
The orphan check is what enforces "trait coherence" in Rust: that there is at most
one implementation of a trait for any given type. The orphan check basically answers
the question "might another crate implement this trait Tr</code> for this type Ty</code>?"</p>
In rustc</code>, this check is performed whenever you implement a trait.
Since you must spell out the type for the impl</code> block,
there is normally no way to encounter an unnameable type there
(unnameable types are types of functions, closures, and coroutines).
However rustc</code> did have an experimental feature "typeof</code>" which could
cause the orphan check to encounter unnameable types, allegedly
(I'm not familiar with the details).
That feature was removed</a>
in late November, and the now unreachable code in the orphan check
that dealt with unnameable types was replaced with panics.</p>
In Creusot, we use the orphan check in the implementation of type invariants</em>.
This feature lets you specify a property that should be satisfied by all values of a type.
For example, you can define a type of integers bounded by 42 as a struct</code> with
an Invariant</code> impl:</p>
struct</span> Bounded42</span>(</span>usize</span>);</span></span>
</span>
impl</span> Invariant</span> for</span> Bounded42</span> {</span></span>
    #</span>[</span>logic</span>]</span></span>
    fn</span> invariant</span>(</span>self</span>)</span> -></span> bool</span> {</span></span>
        pearlite!</span> {</span> self</span>.</span>0</span> <=</span> 42</span>usize</span> }</span> </span></span>
    }</span></span>
}</span></span></code></pre>
All functions that take a Bounded42</code> argument can assume the type invariant,
and all functions that return a Bounded42</code> must prove the type invariant.</p>
Any type Ty</code> has a type invariant, which we determine as follows:</p>

if there is an instance Ty: Invariant</code>, that is a user-provided</em> type invariant;</li>
if there is definitely no such instance, then we fall back to a structural</em> type invariant
derived from the type definition (it basically says that all fields satisfy
their type invariant);</li>
if there is no instance Ty: Invariant</code> in this context,
but we cannot rule it out definitely
(an instance may appear after instantiating some type variables,
possibly using implementations provided by an unknown crate),
then the type invariant is an undefined predicate.</li>
</ul>
The orphan check is what distinguishes between the last two cases.
Furthermore, because type invariants apply to all types, this also concerns
unnameable types: for example if you pass a closure as an argument to a function,
then Creusot will look for its type invariant, involving an orphan check.</p>
The update to the orphan check caused it to panic in this case.</p>
The fix is simple in hindsight: we replace unnameable types (function types)
with the unit type ()</code> before invoking the orphan check.
Indeed, these types should behave the same as far as the orphan check
is concerned: both the unit type and function types from the current crate
or its dependencies are "external types" from the point of view of a
sibling or descendant crate.</p>
It is also possible to fix the orphan check in rustc</code> itself to not
panic in those cases even though they don't happen within rustc</code>.
But our workaround works and we just don't have an incentive to tinker
with it further, at least until that becomes a bigger issue.</p>


Creusot 0.9.0: Launching the Creusot Devlog
2026-01-19T00:00:00+00:00
Begin Devlog</h2>
Welcome to the Creusot Devlog, where we blog about the development of Creusot project,
a deductive verifier for Rust.
Creusot helps you verify that your code is safe from panics,
overflows, and assertion failures, and also that it correctly implements
its formal specification (pre- and post-conditions).</p>
The plan is to have posts accompany our monthly releases</strong>, highlighting key features
and writing about happenings in and around Creusot.</p>
Creusot at POPL</h2>
Last week, the Creusot Team went to POPL 2026, a major academic PL conference.</p>


We presented a tutorial on Creusot. More details below.</a></p>
</li>

Arnaud Golfouse gave a talk at the CPP workshop (Certified Programs and Proofs):</p>

Using Ghost Ownership to Verify Union-Find and Persistent Arrays in Rust</em>,
by Arnaud Golfouse, Armaël Guéneau, Jacques-Henri Jourdan
(paper on HAL</a>, talk on Youtube (at 8h03m)</a>).</li>
</ul>
</li>
</ul>
Upcoming events</h3>
One more Creusot paper will appear in JFLA 2026, a French-speaking academic conference taking place next week. This paper is about verifying an implementation of a tricky tree traversal algorithm</a> (see also Threaded binary tree</em> on Wikipedia</a>) using Creusot:</p>

Boucler la boucle du parcours de Morris</em>, by Arnaud Golfouse and Paul Patault (paper on HAL</a>, code on Zenodo</a>).</li>
</ul>
Also next week, Li-yao Xia will give another presentation of Creusot at the RFMIG meeting
(Rust Formal Methods Interest Group)</a>, online, on Monday, January 26 at 18:00 GMT (19:00 in France). It will focus on a work-in-progress case study:
verifying slice methods in Rust's core library.</p>
What's new in Creusot?</h2>
Creusot 0.9.0 was released earlier this month, right before the start of POPL.</p>
Creusot Tutorial</h3>
The Creusot tutorial walks you through the process of verifying a Rust program with Creusot.
The tutorial is available in the creusot-rs/tutorial</code> repository</a>.
You don't even need to install anything: you can try Creusot online in your browser! See the README</a> for more details.</p>
This uses a DevContainer, made possible by recently added support for installing Creusot with Nix.</p>
Contents of the tutorial</h4>

A gallery of small examples</a> illustrating Creusot's main features.</li>
Exercise 1: Gnome sort (exercise</a>, code</a>)</li>
Exercise 2: Linked lists (exercise</a>, code</a>)</li>
</ul>
Infer trivial loop invariants</h3>
This is a convenience enhancement for type invariants.</p>
A type invariant is a property that all values of a type should satisfy.
This is a natural way to encode well-formedness conditions of many data structures.</p>
For example, below is a type of "ordered pairs", OPair</code>,
with the type invariant that its fields are indeed ordered.</p>
// Ordered pairs</span></span>
pub struct</span> OPair</span>(</span>pub u64</span>,</span> pub u64</span>);</span></span>
</span>
impl</span> Invariant</span> for</span> OPair</span> {</span></span>
    #</span>[</span>logic</span>]</span></span>
    fn</span> invariant</span>(</span>self</span>)</span> -></span> bool</span> {</span></span>
        pearlite!</span> {</span> self</span>.</span>0</span> <=</span> self</span>.</span>1</span> }</span></span>
    }</span></span>
}</span></span></code></pre>
By equipping a type with a type invariant,
every function whose interface involves that type will implicitly assert its type invariant
in the function's preconditions and postconditions.</p>
    #</span>[</span>requires</span>(</span>self</span>.</span>0</span> <</span> self</span>.</span>1</span>)]</span></span>
    // Implicit:</span></span>
    // #[requires(inv(*self))]</span></span>
    // #[ensures(inv(^self))]</span></span>
    pub fn</span> bump</span>(</span>&</span>mut</span> self</span>) {</span></span>
        self</span>.</span>0</span> +=</span> 1</span>;</span></span>
    }</span></span></code></pre>
The problem arises when we use such a type in a loop. For example:</p>
    pub fn</span> bump_loop</span>(</span>&</span>mut</span> self</span>) {</span></span>
        while</span> self</span>.</span>0</span> <</span> self</span>.</span>1</span> {</span></span>
            self</span>.</span>bump</span>()</span></span>
        }</span></span>
    }</span></span></code></pre>
In that loop, we call self.bump</code>, which requires self</code> to satisfy its type invariant.</p>
Previously, we had to explicitly state the loop invariant, that the type invariant is preserved by each iteration of the loop body:</p>
    pub fn</span> bump_loop</span>(</span>&</span>mut</span> self</span>) {</span></span>
        #</span>[</span>invariant</span>(</span>inv</span>(</span>*</span>self</span>))]</span></span>
        while</span> self</span>.</span>0</span> <</span> self</span>.</span>1</span> {</span></span>
            self</span>.</span>bump</span>()</span></span>
        }</span></span>
    }</span></span></code></pre>
This kind of condition easy to forget for newcomers,
and becomes quite cumbersome as more type invariants are involved.</p>
Now this invariant is automatically inserted by Creusot.</p>
That's not all. It may still be desirable to write loops
that don't preserve the type invariant—for example, in the initialization
of a complex data structure.</p>
Although one might imagine a flag to toggle this behavior, we propose an
automatic but conservative solution that guesses right in most cases:
a type invariant is inserted in a loop invariant only if the last
write to a given variable before (re)entering the loop comes from
a function boundary.</p>
For the example above,
self</code> is written to by the caller of the function first, and then
by the bump</code> method in the loop, both of which involve a type invariant assertion,
so we can safely insert that type invariant as a loop invariant.</p>
For a counterexample, below we replaced the bump</code> call with a direct
assignment to a field of self</code>. Such assignments are not required to
preserve the type invariant of self</code> in general (even though in this case it does).
Indeed, we expect field assignments to occur as part of the implementation
of a data structure, temporarily breaking type invariants.
Consequently, Creusot does not insert the type invariant implicitly in this case.
The user can still provide it if necessary.</p>
    pub fn</span> bump_loop_raw</span>(</span>&</span>mut</span> self</span>) {</span></span>
        #</span>[</span>invariant</span>(</span>inv</span>(</span>*</span>self</span>))]</span> // Must be explicit</span></span>
        while</span> self</span>.</span>0</span> <</span> self</span>.</span>1</span> {</span></span>
            self</span>.</span>0</span> +=</span> 1</span>;</span></span>
        }</span></span>
    }</span></span></code></pre>
Creusot decides whether to insert such type invariants by performing
a little static analysis, a standard exercise in compiler writing.</p>
This analysis also detects mutable variables that are not actually written to,
so that Creusot can also insert invariants that say "this value hasn't changed
since the beginning of the loop".</p>
Renamed creusot_std</code></h3>
Creusot's standard library has been renamed from creusot_contracts</code>
to creusot_std</code>.</p>
This library provides macros to enable writing contracts (requires</code>, etc.),
and it also contains contracts for the Rust standard library, hence the
old name creusot_contracts</code>. The new name creusot_std</code> better conveys the
idea that it's a fundamental library to be imported by all Creusot users.</p>
Compatibility with no_std</code></h3>
The creusot_std</code> library now features a flag std</code> which can be disabled
for no_std</code> projects. This is part of ongoing work to support the verification
of low-level embedded code.</p>
Disabling std</code> reduces the dependencies of creusot_std</code> to core</code> and alloc</code>.
This removes contracts for a few data structures such as hashmaps.
In the future, it may be possible to avoid the dependency on alloc</code> as well,
but it seems that most no_std</code> projects also depend on alloc</code> anyway.</p>
Concurrency: atomic invariants</h3>
Creusot takes its first step in the formal verification of concurrent programs.
Our first working example is parallel_add</code></a>
(for comparison, here is the equivalent Rust code</a> without ghost annotations).</p>
This builds on top of the aforementioned work on ghost ownership presented at CPP 2026.
For concurrency, this release makes two key additions to the creusot_std</code> library:
the AtomicI32</code></a>
type—a ghost-aware wrapper around std::sync::atomic::AtomicI32</code></a>—and
a notion of AtomicInvariant</code></a> inspired by Iris</a>, a separation logic framework in Rocq.
For now, this only supports sequential consistency. There is ongoing
work to also provide support for relaxed memory models.</p>
Stay tuned for future updates on Creusot!</p>

Creusot Devlog

Creusot 0.10.0: February update

What's new in Creusot?</h2> This February's release brings a couple of QOL improvements. For the rest, see the Changelog</a>.</p>

Creusot 0.9.0: Launching the Creusot Devlog

What's new in Creusot?</h2>
This February's release brings a couple of QOL improvements. For the rest, see the Changelog</a>.</p>