Rust Dylib Rabbit Holes | Hacker News Reader

Rust Dylib Rabbit Holes

davidlattimore.github.io

63 pointsjmillikin13 comments

> I sometimes wonder if Rust (or more accurately Cargo) needs a third default profile “fastbuild” that doesn’t have debug info and is optimised for building fast.

I’d go even further and say that cargo should have an option for simply checking if the code compiles (and borrow checks), but doesn’t even link it. 95% of the time when I’m writing code, I run cargo to see if the code I just wrote, compiles. Then it tells me about an error, I try to fix it, then run cargo again. In each of these instances I don’t even need to run or even link the code.

I use an IDE with LSP/rust-analyzer support to get errors as I type but it doesn’t catch a lot of errors (and doesn’t seem run borrow checking) so I need to do a cargo build to get the full error report, I just want this loop to be faster.

How that different from cargo check?

Interesting, now I feel like an idiot. I had assumed cargo check performs a superset of cargo build (as in, lint checks/etc) but looking at the docs you’re right, it does seem to be aimed at doing exactly what I describe, skipping final compilation steps and just checking if the code has errors.

Time to re-bind my IDE shortcuts!

Oh but also, from the docs:

> Some diagnostics and errors are only emitted during code generation, so they inherently won’t be reported with cargo check.

I’ll have to see how much this affects my work loop but it’s definitely worth trying.

Huh, I have been programming in rust for a long time and I've never noticed such diagnostics.

Well, unless you count an unintentional LLVM crash as a "diagnostic or error", then I've noticed one exactly once...

I believe post-monomorphization errors don't show in cargo check, and those are rather rare in Rust.

Cargo check won't report linker errors, that the only difference I ever ran into.

Update: after 2 days of replacing my “cargo build” shortcut with “cargo check”, I never saw an error that check didn’t catch.

Granted, most of my build/edit loop consists of attempting to build not-working-yet code anyway, so build was typically halted due to errors before linking happened in the first place, so in practice I don’t think it’s saved me that much time… but in the few cases where everything does build, it’s nice to not have to wait those extra few seconds for the green check (I’m using RustRover for the record.)

Which can be incremented to `cargo watch -x check -x test -x "run --release" --clear` on a side terminal.

You may also find https://github.com/Canop/bacon to complement this type of workflow / mental mode. I keep both bacon and cargo-watch installed and use each regularly but I probably spend more time with bacon for commonplace working sessions.

Also in the ring are https://github.com/eradman/entr and watchexec (which shares code and authorship with cargo-watch IIRC). As you can see I'm a fan of changed-files-automatically-do-things workflows.

> I use an IDE with LSP/rust-analyzer

VS Code does borrow checking for me in the IDE.

Granted, I've only done a hobby / weekend project; so I don't know if larger, industrial strength codebases will hit limitations that I don't see.

A nice article that looks into a specific difference between llvm/lld and gnu ld, when it comes to shared objects on linux.

Note that making shared generics protected breaks pointer equality when multiple shared libraries are involved. I'm pretty sure this is illegal in C++ but I'm not sure about Rust's rules.

Reply on news.ycombinator.com