Skip to content
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

Consider whether bindgen or clang-sys is better placed to generate implicit constructors #1461

Open
adetaylor opened this issue Feb 28, 2025 · 0 comments
Labels
architectural Architectural improvement

Comments

@adetaylor
Copy link
Collaborator

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.
@adetaylor adetaylor added the architectural Architectural improvement label Feb 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architectural Architectural improvement
Projects
None yet
Development

No branches or pull requests

1 participant