Comments (8)
There seem to be three problems here:
- Sometimes bindgen correctly emits the templated type as a Rust generic. We weren't handling that correctly; we were passing such types onto
cxx::bridge
as type aliases and that resulted in errors. Fixed in #107 . Note that this doesn't allow us to use such types in client code, but it means they no longer break usage of downstream types (e.g.Origin
in the above example). bindgen
does not handle types with associated types. This may be a known limitation. Issue reported here in case it's do-able. rust-lang/rust-bindgen#1924- Our suppression of
std::string
is causing trouble when it's used in templated types. Maybe there's some way we can make it more opaque but still allow it.
from autocxx.
To be specific on the last point: we are expunging all mention of std::string
from bindgen output by means of a prelude and a blocklist. So, when we encounter a type (base::StringPiece
) which fundamentally depends on std::string
(or specifically std::string::value_type
) - shock - it doesn't work!
I am planning to see if I can persuade bindgen to output enough of std::string
for this to work, without so much that everything breaks.
from autocxx.
It turns out bindgen does a creditable job of producing bindings for std::string
. I doubt they truly represent the real layout in memory, and of course they don't represent the pinned nature of it, but they are internally consistent and build. However, the arrangement of types generated by bindgen is predictably fragile, and our various alterations break everything. That being the case, here are some options:
- Allow
bindgen
bindings to pass through to the resulting code untouched. Use them as a guide to generate extra bindings, both in thebindgen
output mod, and elsewhere (in thecxx::bridge
mod and the top level mod), but don't change anything. - As above, but do alter types to be non-POD unless the user has specifically asked for them to be POD. This is fiddly.
- As above, but switch from a POD allowlist to a POD blocklist, and pass that blocklist to bindgen such that it can make types opaque.
- Continue to meddle with bindgen bindings as we do now, but allow the user to mark some types as opaque.
from autocxx.
Current state of play:
bindgen
doesn't correctly identify that some types are templated, per rust-lang/rust-bindgen#1924. I'm working on this in the background. For such types, we don't really stand a chance - we inevitably tell C++ that this is a plain old type not a templated type, and that results in compilation failures. That accounts for the need toblock!
some types in my current real-world experiments e.g. https://twitter.com/adehohum/status/1334732132522967041. In general though bindgen does a really remarkable job of passing on the generic-ness of types to us.- cxx does not understand generic types (as far as I understand it) with the exception of those it knows about -
std::vector
, etc. So for other generic types we have to squash them down to a flat type on their way betweenbindgen
andcxx
. - So, since #161, we now recognize the impending doom, and generate a
typedef
in C++ to turn each concrete instance into a type of its own. - We do not attach methods to such types. This could be achieved relatively easily. The same applies to constructors.
- Such types are always opaque.
- So at the moment, such types are only useful if they're returned by one function and then you pass them to another. You can't interact with them in any other way.
- #162 says we don't even test that properly 👍
Next steps here:
- Consider whether we can allow
cxx
to understand generic types. This would be a big lift but would make things much better. - Otherwise, consider attaching methods and constructors to our synthesized concrete types.
- In parallel, continue to work on that
bindgen
stuff.
from autocxx.
cxx does not understand generic types (as far as I understand it) with the exception of those it knows about -
std::vector
, etc. So for other generic types we have to squash them down to a flat type on their way betweenbindgen
andcxx
.
It would be good to get this implemented upstream as extern "C++" { type Container<T>; }
.
from autocxx.
Current state of play here with respect to Chromium:
- https://chromium-review.googlesource.com/c/chromium/src/+/2784885 made that we no longer suffer this problem with
base::StringPiece
(thanks Jan!) - But unfortunately
base::Optional
still seems to run into the same problem (or similar)... I will work on diagnosing
from autocxx.
I posted a status update to rust-lang/rust-bindgen#1924
from autocxx.
I'm removing the "bug" label here since we now gracefully avoid mis-generations in such cases. As such this now becomes a C++ feature for which we need to add support.
from autocxx.
Related Issues (20)
- Github CI fails because of panic in autocxx-bindgen HOT 5
- Support cxx opaque types for subclassing HOT 2
- Can't recognize std::vector<int> HOT 1
- Feature request: be able to implement functions declared in C++ headers HOT 1
- Missing `iterator` definition HOT 5
- "`*const u8` cannot be shared between threads safely" HOT 3
- Cannot pass UniquePtr from Rust to c++ std::unique_ptr HOT 6
- binding generation fails with 16bit floats HOT 2
- Codegen results in function call with incorrect number of arguments HOT 2
- Unable to generate bindings for std::array<unsigned char, 6> HOT 1
- Question: How to "export" (i.e. make `pub`) modules generated by `generate_ns!()`? HOT 1
- Usage of system frameworks (macOS)? HOT 3
- cannot bind rvalue reference of type .. to lvalue of type .. / pointer argument requires that the function be marked unsafe
- Calling protected functions from a Rust subclass
- Generated Binding fails to compile due to due to `redefinition as different kind of symbol` Error HOT 1
- New method of POD-Types not creating a POD rust type
- Unable to find CXX header for C++ HOT 1
- Unable to Call Base Class Functions When Base is a Template Class in autocxx
- autocxx-bindgen upgrade suggestions
- Cannot instantiate C++ `std::vec` of a simple C++ type due to lack of `cxx` `VectorElement` trait implementation. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from autocxx.