Odd behavior generating clang arguments

[joshlf]

I've discovered odd behavior with how bindgen generates flags to pass to clang. In particular, I added a println! here to print the clang_args variable.

Bindgen Invocation and Results

Here are three different invocations of bindgen along with the value of clang_args that was printed as a result:

• bindgen bindgen.h
  • ["--target=x86_64-apple-darwin", "-isystem", "/Library/Developer/CommandLineTools/usr/include/c++/v1", "-isystem", "/usr/local/include", "-isystem", "/Library/Developer/CommandLineTools/usr/lib/clang/9.1.0/include", "-isystem", "/Library/Developer/CommandLineTools/usr/include", "-isystem", "/usr/include", "-isystem", "/System/Library/Frameworks", "-isystem", "/Library/Frameworks", "bindgen.h"]
• bindgen bindgen.h -- -I foo
  • ["--target=x86_64-apple-darwin", "-I", "foo", "-isystem", "/Library/Developer/CommandLineTools/usr/include/c++/v1", "-isystem", "/usr/local/include", "-isystem", "/Library/Developer/CommandLineTools/usr/lib/clang/9.1.0/include", "-isystem", "/Library/Developer/CommandLineTools/usr/include", "-isystem", "/usr/include", "-isystem", "/System/Library/Frameworks", "-isystem", "/Library/Frameworks", "bindgen.h"]
• bindgen bindgen.h -- -foo bar
  • ["--target=x86_64-apple-darwin", "-foo", "bar", "bindgen.h"]
• bindgen bindgen.h -- --target=foo
  • ["--target=foo", "bindgen.h"]

Expected Results

Unrecognized flags such as -foo shouldn't affect other flags that are passed, such as -isystem. I'm not sure whether --target altering what flags are passed is intentional; at the least, bindgen seems smart enough to realize that the --target argument should replace the default --target=x86_64-apple-darwin.

I found this while debugging #1331, and I suspect that they may be related.

[emilio]

So, this is kind of annoying, but it does matter because we get the include directories from clang itself, but pass the original flags so that clang actually reports the directories that will be used, instead of other random stuff.

So if the original flags are not valid, we won't ever find the include paths. I'm not sure this is a bug, fwiw.

I'm aware that the TranslationUnit::parse error message is not great, it'd be awesome to be able to get a better error from clang, but the API doesn't expose anything sensible, so we could only try to guess.

We'd get the same message for "the file you passed doesn't exist", "the target isn't valid", "some other flag is not known"...

[joshlf]

Ah, that's a shame. Oh well. I understand the limitations, though.

[emilio]

Alright, closing then.

Note that there's #297 to consider moving away from libclang, which presumably would allow us to get better error information... But that's a bigger undertaking as well :)