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
Cope with types that have deleted move-constructors #489
Comments
Minimization command for the record
|
Problems here include: void cxxbridge1$std$vector$xyz$pop_back(::std::vector<::xyz> *v, ::xyz *out) noexcept {
::new (out) ::xyz(::std::move(v->back()));
v->pop_back();
} and from: void cxxbridge1$std$vector$xyz$push_back(::std::vector<::xyz> *v, ::xyz *value) noexcept {
v->push_back(::std::move(*value));
::rust::destroy(value);
} The problem here stems from types which have:
This seems to be OK when we I think for now we should cease to generate In the future we might be able to use the wisdom that we'll need to learn in areas around #458 and #258 to determine if there are move constructors, and if so, reinstate auto vector generation. |
You may be able to query whether the move or copy constructor are deleted using the code introduced as part of #426 -- but this may not work if they are implicitly deleted (I don't recall), so it may be best to just avoid generating |
This works but it turns out we need to do the same for copy constructors. It's also a bit messy thus far. Work towards #489.
This works but it turns out we need to do the same for copy constructors. It's also a bit messy thus far. Work towards #489.
This works but it turns out we need to do the same for copy constructors. It's also a bit messy thus far. Work towards #489.
This is a problem encountered on an internal codebase, so I can't give details here, but recording that this bug exists for my own records. Once it's minimized I will post a test case here.
The text was updated successfully, but these errors were encountered: