-
Notifications
You must be signed in to change notification settings - Fork 745
Type parameter is incorrectly stripped when types are not generated #833
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
Labels
Comments
This is a regression from #827. |
cc @fitzgen |
O hey, this is the regression we were hunting down, thanks Xidorn! |
emilio
added a commit
to emilio/rust-bindgen
that referenced
this issue
Jul 21, 2017
…ted_items() for code generation. This standardizes the behavior change at rust-lang#834, but without regressions. I've added a few more tests for rust-lang#833 here.
I think what is going on is that the template analysis needs to consider types even if we aren't codegen'ing them. I'll take a look in a bit. |
bors-servo
pushed a commit
that referenced
this issue
Jul 21, 2017
ir: We really need to traverse all edges for the used template parameter analysis to be sound. Fixes #833
emilio
added a commit
to emilio/rust-bindgen
that referenced
this issue
Jul 21, 2017
…ted_items() for code generation. This standardizes the behavior change at rust-lang#834, but without regressions. I've added a few more tests for rust-lang#833 here.
tmfink
pushed a commit
to tmfink/rust-bindgen
that referenced
this issue
Aug 4, 2017
…ted_items() for code generation. This standardizes the behavior change at rust-lang#834, but without regressions. I've added a few more tests for rust-lang#833 here.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Input C/C++ Header
Bindgen Invocation
Actual Results
Expected Results
like what it would generate when generating type is enabled.
RUST_LOG=bindgen
OutputThe text was updated successfully, but these errors were encountered: