Niklas
Niklas
I took an even closer look at this today. We are a bit sloppy with the return value of `f_mount`. So we missed that it returns an error message after...
> okay, I'm updating the code according to these reviews, but I am not sure whether I can reopen this pr. at the worst case I'll open a new pr....
@emilio, there is also this, but I guess it needs a little bit more careful review.
Not sure what to do about the failure: ``` failures: ---- test_wrap_static_fns stdout ---- In path is ::: tests/expectations/tests/generated/wrap_static_fns Out path is ::: /home/runner/work/rust-bindgen/rust-bindgen/target/debug/build/bindgen-tests-c763cee99ba75d0d/out/wrap_static_fns thread 'test_wrap_static_fns' panicked at bindgen-tests/tests/tests.rs:742:10: Failed...
I reproduced and got a stacktrace locally: ``` thread 'test_wrap_static_fns' panicked at bindgen-tests/tests/tests.rs:742:10: Failed to generate bindings: Codegen(Serialize { msg: "Cannot serialize type kind Opaque", loc: "tests/headers/wrap-static-fns.h:63:56" }) stack backtrace:...
I tried running it manually but it seems to succeed, @emilio how can I trigger the panic by running bindgen? ``` $ cargo run -- bindgen-tests/tests/headers/wrap-static-fns.h Finished `dev` profile [unoptimized...
Fixed the failed CI and rebased Maybe it is a bit excessive to run all the combinations on `aarch64-linux`. Which combination would give most bang for the buck?
@benma ready for review again
Can you do `cargo update --precise` with the libc version used in rust stdlib so that we avoid vendoring two versions?