-
Notifications
You must be signed in to change notification settings - Fork 746
SIGSEGV running rust-bindgen on Objective-C headers #665
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
Comments
Interestingly, changing the input header to only import framework umbrella headers while using the same invocation changes things: Alternative Objective-C Header#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h> // both NSWindow and NSTableView are found in AppKit Actual Results
This looks to be running up against the incompleteness of the Objective-C support presently in |
Thanks for the bug report! |
I've also been trying to use bindgen for AppKit and am running into the same issue (the 2nd one). I think I found the cause though. In the AppKit header file, there is a property with the name
In the I think a potential solution would be to improve the regex matching to include the symbols for C++ operators (+, =, etc.). I'm not too sure on what implications this would have on other codebases as I'm not too familiar with all the bindgen internals, but I can throw together a sample regex expression and make a PR if you think it's a valid solution. |
Alternatively another solution would just be to guard against only C++ functions using the kind to avoid a complex regex expression. Would guarding against |
@svenknobloch I think you'll be interested in #1750.
I tested this with the below test case and it looks like you're right. To update the bug, here's the specific case: input:
Ran via: Expected output (based on recent master):
Annoyingly enough blacklisting doesn't work. I'm guessing because it's at the parse tree phase rather than the generation. |
Input
C/C++Objective-C HeaderBindgen Invocation
Invoked via
cargo build
withRUST_LOG=libbindgen
andRUST_BACKTRACE=1
.Actual Results
Note: No stack trace generated!
Expected Results
At this point, simply successful execution without segfault and generation of bindings, even if incorrect.
The text was updated successfully, but these errors were encountered: