Bindgen panics in Stylo on master #584
Assignees
Labels
Comments
|
I've had a patch to fix this. |
upsuper
added a commit
to upsuper-forks/rust-bindgen
that referenced
this issue
Mar 20, 2017
This should fix rust-lang#584.
|
This wasn't completely fixed by that commit AFAIK. |
fitzgen
pushed a commit
to fitzgen/rust-bindgen
that referenced
this issue
Apr 4, 2017
This should fix rust-lang#584.
|
Making this issue about getting Stylo working with master bindgen again. The libclang 4.0 stuff is tracked in #585 |
|
After much patience, template <class> class RefPtr;
class b;
class A {
typedef b a;
};
template <class c> class e { RefPtr<c> d; };
template <class> class f {};
class g {
f<e<int>> h;
};
class b : g {};
A Servo_Element_GetSnapshot(); |
fitzgen
changed the title
|
Ok, this is an interaction between blacklisting and the template analysis. |
fitzgen
added a commit
to fitzgen/rust-bindgen
that referenced
this issue
Apr 7, 2017
The template analysis operates on whitelisted items, and uses our tracing infrastructure to move between them. Usually, that means we can only reach other whitelisted items by tracing, because the set of whitelisted items is the transitive closure of all the items explicitly whitelisted. The exception is when some type is explicitly blacklisted. It could still be reachable via tracing from a whitelisted item, but is not considered whitelisted due to the blacklisting. The easy fix is to run the template analysis on the whole IR graph rather than just the whitelisted set. This is an approximately one line change in the analysis, however is not desirable due to performance concerns. The whole point of whitelisting is that there may be *many* types in a header, but only a *few* the user cares about, or there might be types that aren't explicitly needed and that are too complicated for bindgen to handle generally (often in `<type_traits>`). In these situations, we don't want to waste cycles or even confuse ourselves by considering such types! Instead, we keep the whitelisted item set around and check by hand whether any given item is in it during the template type parameter analysis. Additionally, we make the decision that blacklisted template definitions use all of their type parameters. This seems like a reasonable choice because the type will likely be ported to Rust manually by the bindgen user, and they will be looking at the C++ definition with all of its type parameters. They can always insert `PhantomData`s manually, so it also gives the most flexibility. Fixes rust-lang#584
This was referenced Apr 7, 2017
fitzgen
added a commit
to fitzgen/rust-bindgen
that referenced
this issue
Apr 10, 2017
The template analysis operates on whitelisted items, and uses our tracing infrastructure to move between them. Usually, that means we can only reach other whitelisted items by tracing, because the set of whitelisted items is the transitive closure of all the items explicitly whitelisted. The exception is when some type is explicitly blacklisted. It could still be reachable via tracing from a whitelisted item, but is not considered whitelisted due to the blacklisting. The easy fix is to run the template analysis on the whole IR graph rather than just the whitelisted set. This is an approximately one line change in the analysis, however is not desirable due to performance concerns. The whole point of whitelisting is that there may be *many* types in a header, but only a *few* the user cares about, or there might be types that aren't explicitly needed and that are too complicated for bindgen to handle generally (often in `<type_traits>`). In these situations, we don't want to waste cycles or even confuse ourselves by considering such types! Instead, we keep the whitelisted item set around and check by hand whether any given item is in it during the template type parameter analysis. Additionally, we make the decision that blacklisted template definitions use all of their type parameters. This seems like a reasonable choice because the type will likely be ported to Rust manually by the bindgen user, and they will be looking at the C++ definition with all of its type parameters. They can always insert `PhantomData`s manually, so it also gives the most flexibility. Fixes rust-lang#584
bors-servo
pushed a commit
that referenced
this issue
Apr 10, 2017
…-analysis, r=emilio Correctly handle blacklisted items in the template analysis The template analysis operates on whitelisted items, and uses our tracing infrastructure to move between them. Usually, that means we can only reach other whitelisted items by tracing, because the set of whitelisted items is the transitive closure of all the items explicitly whitelisted. The exception is when some type is explicitly blacklisted. It could still be reachable via tracing from a whitelisted item, but is not considered whitelisted due to the blacklisting. The easy fix is to run the template analysis on the whole IR graph rather than just the whitelisted set. This is an approximately one line change in the analysis, however is not desirable due to performance concerns. The whole point of whitelisting is that there may be *many* types in a header, but only a *few* the user cares about, or there might be types that aren't explicitly needed and that are too complicated for bindgen to handle generally (often in `<type_traits>`). In these situations, we don't want to waste cycles or even confuse ourselves by considering such types! Instead, we keep the whitelisted item set around and check by hand whether any given item is in it during the template type parameter analysis. Additionally, we make the decision that blacklisted template definitions use all of their type parameters. This seems like a reasonable choice because the type will likely be ported to Rust manually by the bindgen user, and they will be looking at the C++ definition with all of its type parameters. They can always insert `PhantomData`s manually, so it also gives the most flexibility. Fixes #584 r? @emilio
Kowasaki
pushed a commit
to Kowasaki/rust-bindgen
that referenced
this issue
May 2, 2017
This should fix rust-lang#584.
Kowasaki
pushed a commit
to Kowasaki/rust-bindgen
that referenced
this issue
May 2, 2017
The template analysis operates on whitelisted items, and uses our tracing infrastructure to move between them. Usually, that means we can only reach other whitelisted items by tracing, because the set of whitelisted items is the transitive closure of all the items explicitly whitelisted. The exception is when some type is explicitly blacklisted. It could still be reachable via tracing from a whitelisted item, but is not considered whitelisted due to the blacklisting. The easy fix is to run the template analysis on the whole IR graph rather than just the whitelisted set. This is an approximately one line change in the analysis, however is not desirable due to performance concerns. The whole point of whitelisting is that there may be *many* types in a header, but only a *few* the user cares about, or there might be types that aren't explicitly needed and that are too complicated for bindgen to handle generally (often in `<type_traits>`). In these situations, we don't want to waste cycles or even confuse ourselves by considering such types! Instead, we keep the whitelisted item set around and check by hand whether any given item is in it during the template type parameter analysis. Additionally, we make the decision that blacklisted template definitions use all of their type parameters. This seems like a reasonable choice because the type will likely be ported to Rust manually by the bindgen user, and they will be looking at the C++ definition with all of its type parameters. They can always insert `PhantomData`s manually, so it also gives the most flexibility. Fixes rust-lang#584
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See https://bugzilla.mozilla.org/show_bug.cgi?id=1336013
There's a couple places where I think we should stop asserting that we can always generate an IR item, and instead fall back to generating opaque items when we inevitably fail on something.
The text was updated successfully, but these errors were encountered: