I am trying to use RUSTSEC advisory's affected functions info to determine whether code using a "vulnerable" dependency is actually affected or not for the https://github.com/google/osv-scanner tool. (google/osv-scanner#452)

Essentially #21, but using a more naive approach by relying on the compiler optimizing out uncalled functions, which seems to work pretty well in practice. However this requires the functions field to be pretty strict for it to be useful and avoid false negatives/positives.

The definition for the functions field is:

# The path syntax is `cratename::path::to::function`, without any
# parameters or additional information, ...

But I found some (invalid?) "functions" info that doesn't match the above description:

• RUSTSEC-2019-0037 lists a trait implementation instead of the function
• RUSTSEC-2021-0073 also lists a trait impl, and this time with a generic type as well
• Multiple advisories lists macros in the functions field as well (Add affected field macros #664)
• RUSTSEC-2020-0070 lists multiple structs instead of functions

I understand specifying the exact trait impl is accurate than just the function without any parameters, it would be very useful if these can be moved to separate fields so that functions only has functions in it, to reduce the amount of false negatives in tooling consuming this data.

Just for reference here are some of the functions symbols that LLVM emits after being demanged, which is what most call analysis tools will be taking in and have to change to match against the RUSTSEC affected info:

<prost_types::Timestamp as core::convert::From<std::time::SystemTime>>::from // RUSTSEC-2021-0073
smallvec::SmallVec<A>::insert_many // RUSTSEC-2021-0003
<libflate::gzip::MultiDecoder<R> as std::io::Read>::read // RUSTSEC-2019-0010
libflate::huffman::EncoderBuilder::new