Unsafe code highlighting with rust-analyzer

Unknown — Sun, 19 Jun 2022 00:00:00 +0000

This is basically a small appreciation post for semantic highlighting ;)</p> </blockquote>

As Rust devs new and seasoned alike should know, unsafe code is a fickle thing and should be avoided whenever possible. But when the unavoidable need arises, Rust at least requires the explicit use of an unsafe { ... }</code> block expression. This is a nice way of designing this unsafe access, not just because it requires the developer to make a conscious decision about reaching out to this superset of Rust, but also because it allows a reader to quickly skim code for potentially problematic regions when something goes very much wrong.</p>

The thing with that last point though is that an unsafe block only marks a region of code. It doesn't really show the exact operations that are being done in there that are in fact unsafe! This wouldn't necessarily be relevant if unsafe operations in Rust were special in the way they look, but that is not the case at all. Every unsafe operation that exists in Rust is actually one that looks just like a safe one: dereferencing (a raw pointer), reading a (union) field, calling a(n unsafe) function or accessing a (mutable) static.</p>

unsafe</span> {</span>
</span></span>    let</span> value =</span> *</span>totally_not_a_raw_ptr;</span>
</span></span>    let</span> value =</span> very_safe_function</span>(</span></span>)</span></span>;</span>
</span></span>    let</span> value =</span> A_STATIC_BUT_NOT_MUTABLE_I_SWEAR</span>;</span>
</span></span>    let</span> value =</span> this.</span>is_not_a_union;</span>
</span></span></span>}</span></span>
</span></code></pre>

    
        Wouldn't it be nice to make these possibly totally not safe operations stand out?
    </p>
</div>
All of these operations are generally safe, except for when they occur on certain constructs, so knowing whether they are safe or not in an unsafe block requires looking at the target of the operation (or requiring the unsafe blocks to always only surround the unsafe operation itself).</p>
This is where an IDE like rust-analyzer</code> can come into play to help out visually!
Most people should be acquainted with the concept of syntax highlighting, so what if we could make use of that and highlight unsafe operations differently?
This idea sounds great, but in practice the classic approaches to syntax highlighting can't help us here (they're usually defined via a bunch of regular expressions</a>).
After all, we just established that these unsafe operations don't look any different from safe ones.
Fortunately an IDE knows a lot more about code than just the syntax, it knows its semantics</em> and can therefore do the highlighting part on a semantic level.</p>
Enabling unsafe highlighting</a></h3>
With that long and boring introduction out of the way let me show you how to visualize this separation of safe and unsafe operations with rust-analyzer</code>!
Of note is that this requires support from your editor.
After all, the editor is still the responsible entity for rendering the text, as long your editor supports the textDocument/semanticTokens</code> request of the Language Server Protocol</a> you should be good to go.</p>
The exact procedure for enabling this will differ based on your editor of choice, but in VSCode this would be the addition of the following lines to your settings.json</code>:</p>
"</span>editor.semanticTokenColorCustomizations"</span></span>: {</span>
</span></span>    </span>"</span>rules"</span></span></span>:</span> </span>{</span>
</span></span></span>        </span>"</span>*.unsafe:rust"</span></span></span>:</span> </span>"</span>#eb5046"</span></span>
</span></span></span>    }</span></span>
</span></span>}</span></span>
</span></code></pre>

    
        That's it! The curious may want to read the VSCode theming section</a>.
    </p>
</div>
With that set, rust-analyzer</code> will now reveal to us the dark truth of the snippet from earlier!</p>

unsafe</span> {</span>
    let</span> value =</span> *</span>totally_not_a_raw_ptr;</span>
    let</span> value =</span> very_safe_function</span>(</span></span>)</span></span>;</span>
    let</span> value =</span> A_STATIC_BUT_NOT_MUTABLE_I_SWEAR</span>;</span>
    let</span> value =</span> this.</span>is_not_a_union</span>;</span>
</span>}</span>
</span></span></code></pre>

    
        Who would've thought, all of it is unsafe!
    </p>
</div>
Would you look at that!
We can now clearly see which parts of our unsafe block are actually performing unsafe operations.
As a bonus, this also marks the unsafe</code> token itself and the names of unsafe declarations, such as unsafe functions and unsafe traits.</p>
"Unsafe" macros</a></h3>
But there is something we forgot about, something that allows one to easily hide things from the naked eye ... macros!
Pesky macros, they can just expand to unsafe operations as they please in a varying kind of ways.
Worry not though, as rust-analyzer</code> can see right through their tricks!</p>

macro_rules!</span> i_am_potentially_unsafe</span> {</span></span></span>
    (</span>$expr:</span>expr</span>)</span></span> =></span> {</span>
        *</span>$expr
    }</span></span>
</span></span>}</span></span></span>
let</span> reference =</span> &</span>0</span>;</span>
unsafe</span> {</span>
    i_am_potentially_unsafe!</span> {</span> reference </span>}</span></span>;</span>
    i_am_potentially_unsafe</span>! {</span> reference as</span> *const</span> u32</span> </span>}</span></span>;</span>
</span>}</span>
</span></span></code></pre>

    
        Look at that, the language does have unsafe macros! Well, kind of ...
    </p>
</div>
rust-analyzer</code> actually inspects macro invocations for whether they emit unsafe operations and marks the identifier of the macro-call appropriately.
So while Rust itself doesn't really have the concept of an unsafe macro, rust-analyzer</code> kind of imagines it.
There is one case where rust-analyzer</code> deliberately marks a macro expanding to unsafe operations not as unsafe though:</p>
macro_rules!</span> teardown</span> {</span></span></span>
</span></span></span>    (</span>)</span></span> =></span> {</span>
</span></span></span></span>        unsafe</span> {</span> *</span>std::</span></span>ptr::</span></span>null(</span></span>)</span></span> </span>}</span></span>;</span>
</span></span></span></span>    }</span></span>
</span></span></span></span></span>}</span></span></span>
</span>teardown!</span>(</span></span>)</span></span>;</span>
</span></code></pre>

    
        This is clearly doing bad things, but yet it is not marked as unsafe?
    </p>
</div>
Why is that?
Well, while a macro like the one shown here technically does unsafe things under the hood (even worse, it straight up invokes undefined behavior), invoking the macro does not require an unsafe block, so for consistency we aren't marking it as unsafe.
The reasoning here is that usually a macro that wraps its unsafety in an unsafe block does so because it keeps the required invariants up itself, making it safe overall.
If it does not, I'd like to argue that the macro is incorrectly written as one could invoke undefined behavior by invoking the macro without actually noticeably writing unsafe code.</p>
Note, semantic highlighting doesn't stop here!
rust-analyzer</code> has a lot more tags to offer, one of which most of you should be familiar with: the underlining</span> of mutable variables and function calls!
You can see a full list of all the current tags in the manual</a>, but exploring those is for another day.</p>

Lukas Wirth

Unsafe code highlighting with rust-analyzer

IDEs and proc-macros