-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for transparent typedefs #966
base: master
Are you sure you want to change the base?
Conversation
7ce3ac0
to
8a76012
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to take a closer look but over all looks reasonable.
for example. | ||
``` | ||
#define MY_ATTRIBUTES [[nodiscard]] | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes seem unrelated? Seems ok, but maybe worth splitting into its own commit / PR? Or is it some sort of autoformatting i'm not aware of?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/bindgen/ir/ty.rs
Outdated
} => { | ||
// Predict that ret+args will all be erased, but decrement the count whenever we're | ||
// wrong. If the count drops to 0, then type erasure was a no-op after all. | ||
let mut num_erased = 1 + args.len(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd be a bit clearer to do it the other way around. In fact, wouldn't it be a bit nicer to just:
let mut erased_any = false;
macro_rules! try_erase {
($item:tt) => {
if let Some(erased) = eraser.erase_transparent_types(library, $item, mappings) {
erased
} else {
$item.clone()
}
}
Then:
let ret = try_erase!(ret);
...
if erased_any {
return Some(..);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, nice suggestion. I implemented it with a lambda instead of a macro tho.
c4d5245
to
42ae2fe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the lag getting to this. I think this is a nice improvement, though I'm a bit concerned about performance tbh.
See some thoughts above.
pub struct TransparentTypeEraser { | ||
// Remember paths we've already visited, so we don't repeat unnecessary work. | ||
// TODO: how to handle recursive types such as `struct Foo { next: Box<Foo> }`? | ||
known_types: HashMap<Type, Option<Type>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really expect extremely long chains of transparent typedefs? Memoizing this seems over-kill without performance numbers, IMHO...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know about long chains, but I do expect frequent use (typedefs exist to eliminate repetition in typing out complex type names). Is frequent use not sufficient reason to memoize?
ty.clone() | ||
} | ||
}; | ||
let erased_ret = try_erase(ret); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bit unfortunate to do all this cloning unconditionally just to ~almost always throw it away, fwiw...
// NOTE: Because `items` is actually a shared reference to `self`, we cannot take it as | ||
// mutable. We also cannot `drain` or `take` it first, because then the items would be | ||
// unavailable for lookup during the type erasure process. So we mutate a clone, and let the | ||
// caller assign the result back after these shared references have died. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also looks really expensive for big projects... I'd much rather find a way to avoid this unconditional clone of everything... That may mean rejiggering how we store the items, or at the very least changing how we do the pass.
It seems the only reason we need the library around is to do the transparent_alias
stuff, correct?
If so, would it make sense to first do a pass over self.opaque_items
, self.typedefs
, and self.structs
, in order to collect a Path -> Type
map, and only pass that to erase_transparent_types
?
Following #967, introduce
/// cbindgen:transparent-typedef
annotation that causes cbindgen to replace transparent structs and typedefs with their underlying type.This allows the following:
to export as
instead of today's output: