-
Notifications
You must be signed in to change notification settings - Fork 746
Only whitelist items for which we intend to generate bindings #827
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
Only whitelist items for which we intend to generate bindings #827
Conversation
extern "C" { | ||
#[link_name = "_ZN3Foo4testEv"] | ||
pub fn Foo_test(this: *mut Foo); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh. Woops. Need to think about a proper fix some more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I was already reviewing... I suggested a fix below, let me know if it sounds reasonable to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see the reasoning for this change, and this looks good.
However, it doesn't fix the reported bug, which is that the function backing that method gets generated, because now it's in a module children list... We're going to need to look at the impl for Function
too, and look into the signature to see if it's a constructor (we don't keep that around, but it's easy enough to do so).
} | ||
extern "C" { | ||
#[link_name = "_ZN3Foo4testEv"] | ||
pub fn Foo_test(this: *mut Foo); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the problem, actually... This is the function that is panicking on win32, which is unfortunate...
I'll have a fix tomorrow, but I'm calling it a day today. |
ef9136d
to
b392965
Compare
r? @emilio |
This found some existing bugs in |
src/ir/context.rs
Outdated
} | ||
ItemKind::Type(ref ty) => { | ||
if !cc.types { | ||
return false; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woops, I forgot to remove these checks; they're unnecessary now that there is a filter for is_enabled_for_codegen
above.
4a08371
to
cda5e09
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this fix! Neat as usual :)
@@ -1565,6 +1565,8 @@ impl<'ctx> BindgenContext<'ctx> { | |||
assert!(self.current_module == self.root_module); | |||
|
|||
let roots = self.items() | |||
// Only consider items that are enabled for codegen. | |||
.filter(|&(_, item)| item.is_enabled_for_codegen(self)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(It may make sense to merge this with the filter below, your call)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kind of like having it separate, because the latter filter's function is pretty big, and its nice to just separate it out and not worry about it anymore.
impl TraversalPredicate for fn(Edge) -> bool { | ||
fn should_follow(&self, edge: Edge) -> bool { | ||
(*self)(edge) | ||
impl TraversalPredicate for for<'a> fn(&'a BindgenContext, Edge) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't you just do:
impl<'a> TraversalPredicate for fn(&'a BindgenContext, Edge) -> bool {
// ...
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... perhaps ... :-P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh. Huh. Apparently my subconscious was right this time:
$ cargo check
Compiling bindgen v0.27.0 (file:///home/fitzgen/rust-bindgen)
error[E0277]: the trait bound `fn(&'a ir::context::BindgenContext<'_>, ir::traversal::Edge) -> bool: ir::traversal::TraversalPredicate` is not satisfied
--> src/ir/context.rs:179:5
|
179 | / traversal: ItemTraversal<'ctx,
180 | | 'gen,
181 | | ItemSet,
182 | | Vec<ItemId>,
183 | | for<'a> fn(&'a BindgenContext, Edge) -> bool>,
| |__________________________________________________________________________^ the trait `ir::traversal::TraversalPredicate` is not implemented for `fn(&'a ir::context::BindgenContext<'_>, ir::traversal::Edge) -> bool`
|
= help: the following implementations were found:
<fn(&'a ir::context::BindgenContext<'_>, ir::traversal::Edge) -> bool as ir::traversal::TraversalPredicate>
= note: required by `ir::traversal::ItemTraversal`
error[E0277]: the trait bound `fn(&'a ir::context::BindgenContext<'_>, ir::traversal::Edge) -> bool: ir::traversal::TraversalPredicate` is not satisfied
--> src/ir/context.rs:777:5
|
777 | / fn assert_no_dangling_item_traversal<'me>
778 | | (&'me self)
779 | | -> traversal::AssertNoDanglingItemsTraversal<'me, 'ctx> {
780 | | assert!(self.in_codegen_phase());
... |
786 | | traversal::all_edges)
787 | | }
| |_____^ the trait `ir::traversal::TraversalPredicate` is not implemented for `fn(&'a ir::context::BindgenContext<'_>, ir::traversal::Edge) -> bool`
|
= help: the following implementations were found:
<fn(&'a ir::context::BindgenContext<'_>, ir::traversal::Edge) -> bool as ir::traversal::TraversalPredicate>
= note: required by `ir::traversal::ItemTraversal`
error: aborting due to previous error(s)
error: Could not compile `bindgen`.
To learn more, run the command again with --verbose.
@@ -21,7 +21,3 @@ fn bindgen_test_layout_Foo() { | |||
"Alignment of field: " , stringify ! ( Foo ) , "::" , | |||
stringify ! ( bar ) )); | |||
} | |||
extern "C" { | |||
#[link_name = "_ZN3FooD1Ev"] | |||
pub fn Foo_Foo_destructor(this: *mut Foo); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh, nice.
☔ The latest upstream changes (presumably #824) made this pull request unmergeable. Please resolve the merge conflicts. |
Windows uses non-ascii and non-visual characters in mangled names T.T
This makes only generating certain kinds of items more robust, since we don't need to keep checking whether codegen is enabled for different kinds of items all over the place, and can do it the once. It should also reduce the number of items we have to consider in our various analyses for which we don't ultimately care about the answer. Fixes rust-lang#826
cda5e09
to
0b720a3
Compare
@bors-servo r=emilio |
📌 Commit 0b720a3 has been approved by |
…not-to, r=emilio Only whitelist items for which we intend to generate bindings This means that we only need to check in one place, rather than at ever call site. This makes it so that we don't generate methods for the test case, but if I add the `--target` flag like in the original #826 test case, then I get a panic about an unknown ABI. I figure this change is worth landing now, and we can land the fix for the panic as a follow up. r? @upsuper
☀️ Test successful - status-travis |
This means that we only need to check in one place, rather than at ever call site.
This makes it so that we don't generate methods for the test case, but if I add the
--target
flag like in the original #826 test case, then I get a panic about an unknown ABI. I figure this change is worth landing now, and we can land the fix for the panic as a follow up.r? @upsuper