Feature request: allow blocklisting by file

[daviddrysdale]

From #1200 (comment):

If the library you're binding against doesn't have any sort of type / function naming convention or what not, that can indeed be a problem. If you point me to an specific example we can try to figure out what's the best solution for that. Mind opening a new issue for it though?

One specific example of a library that doesn't have an easy library-wide naming convention is BoringSSL / OpenSSL.

We're looking at adding BoringSSL support to the openssl crate via bindgen, and we'd like to avoid including things from system headers in the generated code. I started trying to build an allowlist to just match things from BoringSSL, but I gave up when I reached 75 different prefixes (!).

So I wondered whether adding something like a --blocklist-file "/usr/include.*" option would be feasible?

[daviddrysdale]

Implementation-wise, would adding a location: Option<clang:SourceLocation> field to the Item type be a possible way to go? Most of the places that build new Items have location information available that could be used to populate this, and then Item::is_blocklisted() could check this information against a new BindgenOptions::blocklisted_files option.

Happy to send over a draft PR for this if it sounds helpful/sensible.

(There's one special case that turned up when I was experimenting – some standard integer types from <stdint.h> seem get mapped to Rust integer types regardless of whether they're blocklisted, so there probably needs to be a corresponding special case in BindgenContext::blocklisted_trait_implements_type() to assume that the these integer types are Copy/Clone/Debug.)