Support filtering out dependency source code from coverage counters

[xd009642]

Related to #84943

Sometimes it’s useful to only instrument certain files or functions.

This is also true for code not in your crate but a dependency. Some dependencies may create a large amount of coverage counters, on a closed source project I tried it on syn and serde took up the majority of the counters. Most people testing a crate aren't looking to get coverage of their dependencies as well so it makes sense to not instrument crates that aren't in the project workspace. Plus it should lead to faster run time and faster parsing of coverage reports - though for most projects I'd expect this to be negligible

Can ignore below, I feel that even with half sized hash the chance of hash collisions on ascii strings from mangled function names is probably negligibly low 🤔

It's also worth noting that for function hashes llvm coverage uses a truncated MD5 hash (so 64 bits instead of 128 bits). These hashes are used to create a hashmap of records and if i recall correctly in the profdata implementation last I checked it doesn't check for hash collisions so the more records the greater the chance of coverage data being lost or erroneously linked to a source location due to hash collisions. I'm not sure of the relative risk of this (I'd have to sample a variety of crates to figure this out), but reducing the number of records would mitigate the potential risk here as well. EDIT: I'm actually very curious about the hash collision impact myself so will update if I find anything out 🤔

[xd009642]

If anyone's interested this is the debug printout of the merged profraw files generated from https://github.com/xd009642/llvm-profparser I implemented this, implemented a subset of llvm-profdata show and test against the llvm test files for the util to ensure output is the same so I'm relatively confident of correctness - e.g. func names, hashes and counter values definitely match llvm implementation.

cargo.txt

From just searching the dependencies in cargo's Cargo.toml and counting the times their names show up we get:

• cargo_util: 290 occurrences
• anyhow: 182
• filetime: 90
• git2: 2
• hex: 30
• ignore: 6
• jobserver: 100l
• libc: 16
• log: 258
• shell_escape: 8
• tar: 8
• tempfile: 248
• walkdir: 158

I've excluded all dependencies with 0 mentions and openssl which is mentioned a lot in the code so the 4112 references may come from records within the crate source. It is evident not all dependencies are featured in the counters. So I guess there's some facet of those crates that doesn't allow them to be automatically excluded. Maybe macros could play a part as log uses macros heavily and I'm guessing similar to C++ templates their compilation unit is where they are used