Skip to content

allowlist entries like allowlist_function show no warning when they don't match anything. #2167

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

Closed
noahgibbs opened this issue Feb 22, 2022 · 5 comments · Fixed by #2252
Closed

Comments

@noahgibbs
Copy link

It would be useful if bindgen printed a warning when allowlist_function, allowlist_type, allowlist_var and allowlist_file resulted in no symbols being matched. I know you can't always predict how many symbols are matched with a regexp. But presumably an allowlist entry exists to try to match something.

Right now it silently fails to emit a binding with no warning/error that can be checked for.

A similar warning for header() would also be nice.

(I apologise if there's an optional warning I could turn on. I haven't found one yet.)

Input C/C++ Header

int non_matched_function(int arg);

Bindgen Invocation

  let bindings = bindgen::builder()
    .header("foo.h")
    .allowlist_function("doesnt_match_anything")
    .generate()
    .expect("Unable to generate bindings");

  bindings.write_to_file("./bindings.inc.rs").expect("Couldn't write bindings!");

Actual Results

Bindings are correct (empty). But no warning message is shown.

Expected Results

A warning, such as "allowlist_function doesnt_match_anything matched no symbols!" and possibly "header file foo.h contained no matched symbols."

@acj
Copy link

acj commented Jun 14, 2022

I bumped into this recently and found that it was a logging level issue. The (somewhat confusingly named) record_matches option will print the warnings you're looking for, but env_logger's default log level is error.

$ cat header.h
int non_matched_function(int arg)

$ bindgen header.h --allowlist-function doesnt_match_anything
/* automatically generated by rust-bindgen 0.59.2 */

$ RUST_LOG=warn bindgen header.h --allowlist-function doesnt_match_anything
[2022-06-14T11:45:56Z WARN  bindgen::ir::context] unused option: --allowlist-function doesnt_match_anything
/* automatically generated by rust-bindgen 0.59.2 */

@noahgibbs
Copy link
Author

noahgibbs commented Jun 15, 2022

That sounds fantastic. I'm not having any luck adapting it to use a build.rs file, though. It works fine on the command line, but with cargo and a builder it doesn't seem to be printed, even after I add the .record_matches(true) option and set RUST_LOG. Am I doing something obviously wrong? I'm pretty new to Rust.

Edit to add: ah, okay. Cargo doesn't print almost anything to console, so it'll wind up in the output files. And it doesn't seem to respect RUST_LOG, so it doesn't even end up inside those, even with full verbose options. But there's probably some programmatic way I can set the log level and then check the output files.

I don't think this is going to work for us, though. This is going to be very hard to use when bindgen is a "cargo build" step :-/

@acj
Copy link

acj commented Jun 19, 2022

It works fine on the command line, but with cargo and a builder it doesn't seem to be printed

I haven't tried it with build.rs, but you might need to do env_logger::init(); before calling bindgen. That worked for me with RUST_LOG=warn cargo xtask ... in a similar use case.

Yeah, the current warning mechanism feels clunky. It would be nice if you could call a function on the builder to check matches, or maybe inspect something on the Bindings struct after you generate.

@noahgibbs
Copy link
Author

There's an internal function to check for unmatched Rules. That's how the printed warning works. But it looks like it's not meant for external consumption.

@noahgibbs
Copy link
Author

Looks like your fix does work for our case. Thank you! With a little grepping the output we can get the missed imports.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants