False positives in easy testcase.

[vi]

$ cargo new --bin geig
     Created binary (application) `geig` project

$ cd geig/

$ echo 'slab_typesafe = "*"' >> Cargo.toml 

$ cargo geiger
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating registry `https://github.com/rust-lang/crates.io-index`            
    Checking slab v0.4.0
    Checking slab_typesafe v0.1.2
    Checking geig v0.1.0 (file:///tmp/experimenting/geig)
    Finished dev [unoptimized + debuginfo] target(s) in 12.17s

Metric output format: x/y
x = unsafe code used by the build
y = total unsafe code found in the crate

Functions  Expressions  Impls  Traits  Methods  Dependency

0/0        0/0          0/0    0/0     0/0        geig v0.1.0 (file:///tmp/experimenting/geig)
0/0        0/0          0/0    0/0     2/2      ☢ └── slab_typesafe v0.1.2
0/0        23/23        0/0    0/0     2/2      ☢     └── slab v0.4.0

$ cargo geiger --version
cargo-geiger 0.3.0

$ rustc --version
rustc 1.28.0-nightly (e3bf634e0 2018-06-28)

Expected 0/2, 0/23, 0/2.

[anderejd]

Thanks! This is a duplicate of #3 but with a nice minimal test case so let's keep both issues open until solved.

EDIT: I misinterpreted the issue title. This is not test related, all unsafe in this case is located in normal code.

What needs to be added to cargo-geiger to in order to solve this issue is to start tracking each function for inclusion in the build. I'm not aware of any way to do this yet. Can rustc be told to emit this information? Is it already present in the output folder?

[pinkforest]

Great issue thanks 💜 !

cargo-geiger 0.11.2 w/ nightly-x86_64-unknown-linux-gnu & rustc 1.59.0-nightly (f1ce0e6a0 2022-01-05)

0/0        0/0          0/0    0/0     0/0      ?  geig 0.1.0
0/0        6/6          0/0    0/0     2/2      !  └── slab_typesafe 0.1.3
0/0        25/25        0/0    0/0     3/3      !      └── slab 0.4.5

0/0        31/31        0/0    0/0     5/5    

Issue 1

pub unsafe fn - these are probably not used why do we care?

src/lib.rs:    /// unsafe {
src/lib.rs:    pub unsafe fn get_unchecked(&self, key: K) -> &V {
src/lib.rs:    /// unsafe {
src/lib.rs:    pub unsafe fn get_unchecked_mut(&mut self, key: K) -> &mut V {

Issue 2

slab sub-dependency tree somehow is missed

0/0        25/25        0/0    0/0     3/3      ☢️  slab 0.4.5
0/0        0/4          0/0    0/0     0/0      ❓ └── serde 1.0.133
0/0        0/0          0/0    0/0     0/0      ❓     └── serde_derive 1.0.133
0/0        0/12         0/0    0/0     0/3      ❓         ├── proc-macro2 1.0.36
0/0        0/0          0/0    0/0     0/0      🔒         │   └── unicode-xid 0.2.2
0/0        0/0          0/0    0/0     0/0      ❓         ├── quote 1.0.14
0/0        0/12         0/0    0/0     0/3      ❓         │   └── proc-macro2 1.0.36
0/0        0/47         0/3    0/0     0/2      ❓         └── syn 1.0.85
0/0        0/12         0/0    0/0     0/3      ❓             ├── proc-macro2 1.0.36
0/0        0/0          0/0    0/0     0/0      ❓             ├── quote 1.0.14
0/0        0/0          0/0    0/0     0/0      🔒             └── unicode-xid 0.2.2

0/0        25/88        0/3    0/0     3/8    

More from slab.rs

src/lib.rs: /// unsafe {
src/lib.rs: pub unsafe fn get_unchecked(&self, key: usize) -> &T {
src/lib.rs: /// unsafe {
src/lib.rs: pub unsafe fn get_unchecked_mut(&mut self, key: usize) -> &mut T {
src/lib.rs: /// let (value1, value2) = unsafe { slab.get2_unchecked_mut(key1, key2) };
src/lib.rs: pub unsafe fn get2_unchecked_mut(&mut self, key1: usize, key2: usize) -> (&mut T, &mut T) {

So yes I think we need to trace function calls as using pub unsafe fn requires the caller to be unsafe.

But on otherhand there are functions that require caller to use them in unsafe block.

But for proper analysis we need to determine whether there is an impact.