Open cehteh opened 4 months ago
The error I see is
thread '<unnamed>' panicked at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/syn-1.0.109/src/lit.rs:1020:13:
Unrecognized literal: `c""`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
confirming that geiger is using syn 1.0.109 https://github.com/geiger-rs/cargo-geiger/blob/master/geiger/Cargo.toml#L18
Upstream bug https://github.com/geiger-rs/cargo-geiger/issues/517
Upstream PR https://github.com/geiger-rs/cargo-geiger/pull/518 seems to be stalled
Development of geiger in general seems to be stalled.
It might be easier to replace geiger with an alternative.
https://github.com/cackle-rs/cackle/blob/main/src/unsafe_checker.rs does similar and doesnt look very complicated. ping @davidlattimore
https://github.com/daminals/unsafe-parser also looks interesting, but isnt published yet. ping @daminals
Another approach would be to make "geiger-count" an optional feature until they have fixed their problems.
Cackle uses two forms of checking for unsafe. It passes -Funsafe-code
to rustc when compiling the crate and it also tokenises the source of the crate looking for the unsafe
keyword. Neither is 100% and even with the two being used in conjunction, I think it's still possible to use unsafe from code emitted by a proc-macro. I haven't looked at how
cargo-geiger` is implemented, but presumably it has a similar limitation.
One downside to Cackle as a replacement is that it's currently ELF-only, so doesn't replace geiger for use on Mac and Windows. Although presumably most use is via CI, which is presumably mostly on Linux, so maybe that doesn't matter too much.
edit: But if you're just looking to copy the code that checks for unsafe
from cackle and use it in cargo-crev
, then the ELF-specific side of Cackle would be sidestepped.
I think checking for 'unsafe' shouldn't even a be a part of crev. crev is about a trust infrastructure, it manages a harness for reviewing code but it shouldn't be the linting tool. More proper would be to add lints to clippy which check for unsafe code or require it to have a '// SAFETY:' comment and so on. Then crev may eventually have some structured comments like "has unsafe", "all unsafe code is audited and fine", "doubtful use of unsafe", ...
This comes down to that crev gives higher guarantees than that the code is just well written and (memory-)safe. Eventually it should assure that a crate does what it promises. This covers certain correctness assertions as well, like memory leaks, deadlocks, correctly validating input data and more.
cargo crev verify --show-all
panics in presence of raw C string literalsc"like this"
. Cargo crev will then hang when a tread paniced. The panic is not a direct bug in crev itself, it rather stems from the fact that some of its dependencies (geiger) still use syn 1.x which does not support the new (rust 1.77) C string literal syntax.Question is how can this handled more graceful?