Add --blocklist-file option #2097
Conversation
|
|
daviddrysdale
force-pushed
the
blocklist-file
branch
from
7be4f16 to
4b11ab5
Compare
|
r? @emilio (As far as I can tell the |
|
☔ The latest upstream changes (presumably 9738fb9) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Sorry for the massive lag here. So my main concern with this is that tracking the location of a type is a bit tricky in presence of forward-declarations.
Should a forward declaration of a type in a blocklisted file be treated as a usual forward declaration, or should it be blocked? Whatever behavior we want, it probably needs tests.
If we're associating a canonical location to every type it might make sense to look into allowlisting by file, which is also a fairly requested feature. But that can be a follow-up.
src/ir/item.rs
Outdated
| @@ -635,6 +644,15 @@ impl Item { | |||
| return true; | |||
| } | |||
|
|
|||
| if let Some(location) = &self.location { | |||
| let (file, _, _, _) = location.location(); | |||
| if let Some(filename) = file.name() { | |||
There was a problem hiding this comment.
Can we avoid doing all the checks and so on if the user doesn't provide any blocklisted file?
Update Item to hold a `clang::SourceLocation` and use this to allow blocklisting based on filename. The existing code has a special case that always maps <stdint.h> integer types to corresponding Rust integer types, even if the C types are blocklisted. To match this special case behaviour, also treat these C <stdint.h> types as being eligible for derived Copy/Clone/Debug traits. Fixes rust-lang#2096
- struct with normal fwd decl and blocklisted definition ignored - struct with blocklisted fwd decl and normal definition emitted
daviddrysdale
force-pushed
the
blocklist-file
branch
from
4b11ab5 to
46a7d0b
Compare
|
(First commit is just a rebase onto current
So I added a test and the current behaviour is that the location of a |
| // Sized integer types from <stdint.h> get mapped to Rust primitive | ||
| // types regardless of whether they are blocklisted, so ensure that | ||
| // standard traits are considered derivable for them too. | ||
| None => match name { |
There was a problem hiding this comment.
I'm not a huge fan of this since it might run very often, but I guess we can optimize it if / when the time comes.
|
I am working on adding a bindgen backend to openssl-sys, and I would very much appreciate |
Ah, that's the other way round from how I was trying to do the same thing! The motivation for #2096 was to narrow down the output of @benbrittain's work auto-generating BoringSSL bindings – I was trying to |
|
I think that would have trouble with system headers installed outside of /usr/include and OpenSSL headers inside of /usr/include. |
|
#2122 for |
Update Item to hold a
clang::SourceLocationand use this to allowblocklisting based on filename.
The existing code has a special case that always maps <stdint.h> integer
types to corresponding Rust integer types, even if the C types are
blocklisted. To match this special case behaviour, also treat these
C <stdint.h> types as being eligible for derived Copy/Clone/Debug
traits.
Fixes #2096