Add support for transparent typedefs #966
Conversation
scovich
force-pushed
the
transparent-typedef
branch
from
7ce3ac0
to
8a76012
Compare
scovich
changed the title
| for example. | ||
| ``` | ||
| #define MY_ATTRIBUTES [[nodiscard]] | ||
| ``` |
There was a problem hiding this comment.
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.
I was just fixing broken indentation in the existing .md, so that bullets would render correctly. If you hide whitespace changes the diff disappears:
Happy to split it out if it's too noisy/annoying, tho.
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.
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.
Ah, nice suggestion. I implemented it with a lambda instead of a macro tho.
scovich
force-pushed
the
transparent-typedef
branch
from
c4d5245
to
42ae2fe
Compare
| 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.
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.
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.
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.
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-typedefannotation 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: