Description
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 🤔