Can't pass a std::vector<int>

[scullionw]

Expected Behavior

I can pass std::vector<int32_t>, but the the c++ library I want to use uses int, not int32_t

std::vector<int> build_array() {
    auto values = std::vector<int> {1,2,3,4,5};
    for (auto& v: values) v = v * 2;
    return values;
}

Not sure how to get around this since I can't impl VectorElement for c_int due to the orphan rule? There must be something easy I'm missing..

Actual Behavior

   Compiling autoprint v0.1.0 (/Users/scullionw/Projects/autoprint)
error[E0277]: the trait bound `autocxx::c_int: VectorElement` is not satisfied
  --> /Users/scullionw/Projects/autoprint/include-rs/12075411190909706338.rs:1:2988
   |
1  | ...xx_wrapper () -> UniquePtr < CxxVector < c_int > > ; type c_int = autocxx :: c_int ; include ! ("wrapper/wrapper.h") ; include ! ("aut...
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `VectorElement` is not implemented for `autocxx::c_int`
   |
  ::: /Users/scullionw/.cargo/registry/src/github.com-1ecc6299db9ec823/cxx-1.0.46/src/unique_ptr.rs:18:8
   |
18 |     T: UniquePtrTarget,
   |        --------------- required by this bound in `UniquePtr`
   |
   = note: required because of the requirements on the impl of `UniquePtrTarget` for `CxxVector<autocxx::c_int>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: could not compile `autoprint`

To learn more, run the command again with --verbose.

Specifications

• Version: autocxx = "0.6.0" cxx = "1.0.46" rustc 1.53.0-nightly
• Platform: macOS 11.2.3

[adetaylor]

Thanks for the report. I agree this is something which needs addressing in autocxx (or maybe cxx).

Options are:

• Support variable-length std::os::raw::c_* int types in cxx itself. The autocxx::c_* types are really a bit of a workaround. See Adding windows pointer/integer data types dtolnay/cxx#254, which isn't quite this issue, but closely relates.
• autocxx generates impl UniquePtr<autocxx::c_int> {} and impl CxxVector<autocxx::c_int> {} within all FFI bindings mods. (Or it could be smarter and figure out if they're actually needed). Until I try this, I'm not sure if this will hit the orphan rule either.

Hopefully I'll get to give it a try in the next couple of days. If you could raise a pull request with a new (failing) test against engine/src/integration_tests.rs that'd accelerate matters :)

[dtolnay]

Support variable-length std::os::raw::c_* int types in cxx itself. The autocxx::c_* types are really a bit of a workaround.

This is my preference. Built in binding for all the type names in https://doc.rust-lang.org/stable/std/os/raw/index.html.

[scullionw]

added test #423

[scullionw]

on a related note, is there any way to have the behaviour of cxx with autocxx, in regards to int? Unless i'm misremembering, with cxx could call a function that returns an int and get a i32 directly in rust. With autocxx I have to make a shim function to extract i32s from autocxx::c_int's newtype.

[adetaylor]

Thanks @scullionw. Per dtolnay's comment, I think I'll plan to make a PR against cxx to add native cxx support for these types and therefore entirely remove the autocxx::c_whatever wrappers. This should resolve the concerns in your previous comment too (I hadn't realized there was a way that cxx supported ints; I wonder if it's just luck that int lined up with i32 on some systems).

[adetaylor]

Note to self (mostly): I looked into what it would take to support this in cxx. It appears to be extremely straightforward because there's already a CChar inside Atom and we would just want to follow the exact same pattern.

[adetaylor]

Working on this here: dtolnay/cxx#874