-
Notifications
You must be signed in to change notification settings - Fork 149
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
Member initializers are ignored when checking for default constructors #816
Comments
Workaround with minimal change on the C++ side: define an explicit default constructor (either If #815 is fixed before this, then |
This now tracks most of the information about which C++ special member functions are implicit/explicit/deleted/etc for most of the common cases. This information was needed in several places, which were each using different approximations that failed in different ways, so unify those to get it all working. Also add a bunch of tests around the various cases to keep this working. This assumes that any non-analyzed types (except some built-in ones which are handled specially) have no implicit special member functions, instead of the previous behavior which assumed they all existed if the analyzed type had explicit declarations. This should generate functional code for more situations, but it will skip some optional things (such as moveit traits and make_unique) for additional types. If you run into issues with those things disappearing after this change, make sure all dependencies of the type (superclasses and member types) have a `generate!`/`generate_pod!`. Added TODOs for the following unhandled parts: * google#815 (this is a Clang warning anyways, TODOs show all the places to change to fix it) * google#816 (this just means we ignore some implicit constructors which do exist) Also added TODOs related to the followig issues, which limit what can be tested but aren't made better or worse by this change: * google#832 (this one affects lots of areas) * google#829 (this one's pretty prone to unexpected behavior) Also fixed some existing bugs which are surfaced by generating more trait implementations for types in the existing tests: * Use the correct C++ name for destructors of nested types * Handle trait methods for types that end up ignored
This now tracks most of the information about which C++ special member functions are implicit/explicit/deleted/etc for most of the common cases. This information was needed in several places, which were each using different approximations that failed in different ways, so unify those to get it all working. Also add a bunch of tests around the various cases to keep this working. This assumes that any non-analyzed types (except some built-in ones which are handled specially) have no implicit special member functions, instead of the previous behavior which assumed they all existed if the analyzed type had explicit declarations. This should generate functional code for more situations, but it will skip some optional things (such as moveit traits and make_unique) for additional types. If you run into issues with those things disappearing after this change, make sure all dependencies of the type (superclasses and member types) have a `generate!`/`generate_pod!`. Added TODOs for the following unhandled parts: * google#815 (this is a Clang warning anyways, TODOs show all the places to change to fix it) * google#816 (this just means we ignore some implicit constructors which do exist) Also added TODOs related to the followig issues, which limit what can be tested but aren't made better or worse by this change: * google#832 (this one affects lots of areas) * google#829 (this one's pretty prone to unexpected behavior) Also fixed some existing bugs which are surfaced by generating more trait implementations for types in the existing tests: * Use the correct C++ name for destructors of nested types * Handle trait methods for types that end up ignored
Next step here is to add a failing test. Marking 'good first issue' for anyone who wants to do that. |
Expected Behavior
If members of types without default constructors have default initializers, they should not prevent treating a class as though it has a default constructor, when the default constructor is defaulted (implicitly or explicitly).
Actual Behavior
Only the types of member variables are examined.
I'm working on implementing more complete logic for detecting types with default constructors, but this needs more information from bindgen (see #124) so I'm going to leave it for now.
The text was updated successfully, but these errors were encountered: