You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In implicit_constructors.rs we work out what types have, err, implicit constructors of the various types (default, move, copy, etc.) Most of this logic was heroically contributed by @bsilver8192 and has really stood the test of time, very few problems have been reported.
However it does limit us: as of #1456 we no longer alter the output of bindgen, we just augment it. This has increased our sensitivity to bugs in bindgen. Ideally, we'd mark all non-POD types as "opaque" in bindgen - but we can't do that because this constructor analysis requires us to see each field inside the type.
It would be much better if we could contribute an upstream bindgen change to ask bindgen to generate bindings for each implicit constructor. It's probably in a better place to do it; bindgen may simply be able to ask libclang to tell it about the implicit constructors which are applicable.
We could then:
Throw away this logic (which, as noted, is amazing, but also a bit terrifying to have in a tool which is two steps away from the source of truth within libclang)
Instruct bindgen to generate all types as opaque unless they've explicitly been marked as POD
Reduce our sensitivity to bindgen bugs.
The text was updated successfully, but these errors were encountered:
In
implicit_constructors.rs
we work out what types have, err, implicit constructors of the various types (default, move, copy, etc.) Most of this logic was heroically contributed by @bsilver8192 and has really stood the test of time, very few problems have been reported.However it does limit us: as of #1456 we no longer alter the output of bindgen, we just augment it. This has increased our sensitivity to bugs in bindgen. Ideally, we'd mark all non-POD types as "opaque" in bindgen - but we can't do that because this constructor analysis requires us to see each field inside the type.
It would be much better if we could contribute an upstream bindgen change to ask bindgen to generate bindings for each implicit constructor. It's probably in a better place to do it; bindgen may simply be able to ask libclang to tell it about the implicit constructors which are applicable.
We could then:
The text was updated successfully, but these errors were encountered: