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

Don't generate bindings for move constructors #456

Closed
martinboehme opened this issue Apr 29, 2021 · 0 comments · Fixed by #458
Closed

Don't generate bindings for move constructors #456

martinboehme opened this issue Apr 29, 2021 · 0 comments · Fixed by #458

Comments

@martinboehme
Copy link
Collaborator

As I discovered in the context of investigating #426, autocxx currently generates bindings for move constructors because it thinks they're copy constructors.

For the time being, we shouldn't generate bindings for move constructors at all, as it currently isn't possible to use them properly from Rust anyway. We'll need to emit some annotation in bindgen to allow us to distinguish copy constructors and move constructors. I think this could be an attribute called special_member, so we would have #[special_member = "copy_ctor"], #[special_member = "move_ctor"], and so on.

Longer term, we'll want to use the moveit crate to generate bindings to move constructors -- this is tracked in #379.

martinboehme added a commit to martinboehme/rust-bindgen that referenced this issue Apr 29, 2021
See google/autocxx#456 for details.

If I was submitting this upstream, I would have put the information
about special members directly in the MethodKind enum, but that would
have been a pretty invasive change that could cause merge conflicts when
merging from upstream. I've therefore decided to put add a separate enum
that is used in as few places as possible.
martinboehme added a commit to martinboehme/rust-bindgen that referenced this issue Apr 29, 2021
See google/autocxx#456 for details.

If I was submitting this upstream, I would have put the information
about special members directly in the MethodKind enum, but that would
have been a pretty invasive change that could cause merge conflicts when
merging from upstream. I've therefore decided to put add a separate enum
that is used in as few places as possible.
martinboehme added a commit to martinboehme/autocxx that referenced this issue Apr 30, 2021
For details, see google#456.

I'm duplicating some code from `get_bindgen_original_name_annotation` in
`get_bindgen_special_member_annotation` because I plan to move the
former function to a different module when I implement support for
nested types.
lightsofapollo pushed a commit to lightsofapollo/rust-bindgen that referenced this issue Oct 19, 2021
See google/autocxx#456 for details.

If I was submitting this upstream, I would have put the information
about special members directly in the MethodKind enum, but that would
have been a pretty invasive change that could cause merge conflicts when
merging from upstream. I've therefore decided to put add a separate enum
that is used in as few places as possible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant