thread 'main' panicked at 'TranslationUnit::parse failed', libcore/option.rs:960:5 - with --target=path/to/target.json

[alex]

cargo recently gained the ability for --target to point a JSON file, instead of being the name of a target found in RUST_TARGET_PATH.

Using bindgen in a build script when compiling with --target=path/to/target.json produces sadness:

+ [running] ['cargo', 'xbuild', '--target', '/home/travis/build/alex/linux-kernel-module-rust/tests/../x86_64-linux-kernel-module.json']
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling linux-kernel-module v0.1.0 (file:///home/travis/build/alex/linux-kernel-module-rust)
error: failed to run custom build command for `linux-kernel-module v0.1.0 (file:///home/travis/build/alex/linux-kernel-module-rust)`
process didn't exit successfully: `/home/travis/build/alex/linux-kernel-module-rust/tests/printk/../target/debug/build/linux-kernel-module-49ebd67b170fe49c/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-changed=src/bindings_helper.h
--- stderr
thread 'main' panicked at 'TranslationUnit::parse failed', libcore/option.rs:960:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:511
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:426
   6: rust_begin_unwind
             at libstd/panicking.rs:337
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:92
   8: core::option::expect_failed
             at libcore/option.rs:960
   9: <core::option::Option<T>>::expect
             at /checkout/src/libcore/option.rs:312
  10: bindgen::ir::context::BindgenContext::new
             at /home/travis/.cargo/registry/src/jiasu.xzqcsaa.nyc.mn-1ecc6299db9ec823/bindgen-0.37.0/src/ir/context.rs:559
  11: bindgen::Bindings::generate
             at /home/travis/.cargo/registry/src/jiasu.xzqcsaa.nyc.mn-1ecc6299db9ec823/bindgen-0.37.0/src/lib.rs:1634
  12: bindgen::Builder::generate
             at /home/travis/.cargo/registry/src/jiasu.xzqcsaa.nyc.mn-1ecc6299db9ec823/bindgen-0.37.0/src/lib.rs:1102
  13: build_script_build::main
             at ./build.rs:72
  14: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
  15: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  16: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  17: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  18: std::rt::lang_start
             at /checkout/src/libstd/rt.rs:74
  19: main
  20: __libc_start_main
  21: <unknown>

Full output in CI at https://travis-ci.org/alex/linux-kernel-module-rust/builds/392023111

And the diff showing the change that produces this at https://github.com/alex/linux-kernel-module-rust/pull/50/files

[alex]

(Probably worth mentioning that I'm not positive this is a bindgen vs. a cargo bug, but bindgen lost the coin flip 😬 )

[mbalex99]

I am experiencing the same thing when running

cargo lipo --release on https://github.com/spacejam/rust-rocksdb

• cargo-lipo 1.0.3

[joshlf]

I am experiencing this when using -- to separate bindgen args from Clang args:

$ bindgen bindgen.h -- -target foo
thread 'main' panicked at 'TranslationUnit::parse failed', libcore/option.rs:987:5

[emilio]

That means that the arguments are probably invalid.

[joshlf]

Would it be possible to get the error output from libclang itself in order to give a more descriptive error about what went wrong? I finally got this to work by passing --target=x86_64-pc-linux-elf. It'd be nice to know, for example, that it was the argument to --target that was the issue, not the --target flag itself.

[emilio]

Let's keep this issue for the first comment, which I still haven't had time to investigate (sorry @alex!).

The failure in #1331 (comment) is due to invalid arguments. I'm aware that this error message is not great at all, but right now there's no way (at least that I know of) to get a more sensible error message from libclang. I could try to submit patches to libclang to improve this, I've done that for other stuff in the past, but not sure I'll have the time for it.

Possible errors for this message include: bogus flags, unknown file / directories passed into clang, etc...

We could try to some guessing, but it'd be just that, guessing. You need (again, AFAIK) a translation unit to get diagnostics from clang.

[joshlf]

Yeah, that's a shame. A patch to libclang would obviously be nice eventually, but of course that'd take time. For the time being, perhaps a message like "libclang error; possible reasons include invalid arguments, missing files, ". At least that way, it'd make it clear that it's an opaque error from libclang and we can't give any more detail.

[emilio]

Yeah, that sounds reasonable to me, it's really hard to have a worse error message than what we have now ;).

Want to submit a PR for that? Otherwise I can get to it when I have a bit of free time. Thanks!

[joshlf]

I'm happy to submit a PR, but do you happen to know what a more complete set of examples would be? I'd like it to be as exhaustive as possible. So far, you mentioned:

• Invalid flag syntax
• Unrecognized flags
• Unrecognized flag arguments
• File I/O errors

Anything else?

[emilio]

Nothing else comes to mind off-hand...

Probably worth mentioning in the error message to file an issue if the cause of the particular error isn't listed there? :)

[joshlf]

Sounds good!