False negative results on dtoa 0.4.4

[Nemo157]

Running cargo-geiger against dtoa v0.4.4 it reports that it has no unsafe code, and uses forbid(unsafe_code), despite neither of these being true.

It appears that parsing the main file is failing, but it seems wrong for this to result in 0 counts rather than some sort of indeterminate status.

> cargo download -x dtoa=0.4.4 && cd dtoa-0.4.4
INFO: cargo-download v0.1.2
INFO: Latest version of crate dtoa=^0.4.4 is 0.4.4
INFO: Crate `dtoa==0.4.4` downloaded successfully
INFO: Crate content extracted to ./dtoa-0.4.4/
> cargo geiger
    Checking dtoa v0.4.4 (/tmp/tmp.VYgoVrZqbY/dtoa-0.4.4)
[...rustc warnings...]
    Finished dev [unoptimized + debuginfo] target(s) in 0.52s
Failed to parse file: /tmp/tmp.VYgoVrZqbY/dtoa-0.4.4/src/lib.rs, Syn(Error("expected `:`"), "/tmp/tmp.VYgoVrZqbY/dtoa-0.4.4/src/lib.rs")
    Scanning done

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

Symbols:
    :) = No `unsafe` usage found, declares #![forbid(unsafe_code)]
    ?  = No `unsafe` usage found, missing #![forbid(unsafe_code)]
    !  = `unsafe` usage found

Functions  Expressions  Impls  Traits  Methods  Dependency

0/0        0/0          0/0    0/0     0/0      :) dtoa 0.4.4

0/0        0/0          0/0    0/0     0/0

WARNING: Dependency file was never scanned: /tmp/tmp.VYgoVrZqbY/dtoa-0.4.4/src/lib.rs
> cargo geiger --version
cargo-geiger 0.9.0

[Nemo157]

Opened dtolnay/syn#746 about syn's failure to parse the file, but I think the behaviour of showing 0 when parsing a crate fails is still a cargo-geiger issue. (And saying that forbid(unsafe_code) exists is definitely a bug).

[anderejd]

Thanks for the report! This looks very wrong indeed ><

[ralpha]

Also found some false negatives while looking at some creates.

For example (from png p.o.v.):

Functions  Expressions  Impls  Traits  Methods  Dependency

0/0        0/0          0/0    0/0     0/0      :) png 0.16.7
0/0        0/0          0/0    0/0     0/0      ?  ├── bitflags 1.2.1
5/6        108/156      0/0    0/0     0/0      !  ├── crc32fast 1.2.0
0/0        0/0          0/0    0/0     0/0      ?  │   └── cfg-if 0.1.10
0/0        0/0          0/0    0/0     0/0      :) ├── deflate 0.8.6
0/0        0/0          0/0    0/0     0/0      :) │   ├── adler32 1.2.0
1/1        215/215      0/0    0/0     0/0      !  │   └── byteorder 1.3.4
0/0        0/0          0/0    0/0     0/0      ?  └── miniz_oxide 0.4.2
0/0        0/0          0/0    0/0     0/0      :)     └── adler 0.2.3

6/7        323/371      0/0    0/0     0/0    

miniz_oxide 0.4.2 is marked as ? but when looking at code:
https://github.com/Frommi/miniz_oxide/blob/master/miniz_oxide/src/lib.rs#L25
https://docs.rs/miniz_oxide/0.4.2/src/miniz_oxide/lib.rs.html#25

Also found some more before, but can not remember what crate it was.

Edit: Looks like the issue above is a false positive, mine is a false negative. So are slightly different.

[ralpha]

It looks like my issue is because miniz_oxide is build using a build.rs script.
When adding #![forbid(unsafe_code)] is added to the build.rs it does flag the crate as safe.
This is also true for other crates.

[anderejd]

Thanks for sharing your solution!

I opened a new issue to discuss build.rs: #116