Is loading a plugin expected to change include search directories?

Clang Frontend
1

I'm seeing some unexpected behavior when loading a plugin for Clang. Essentially, it appears that loading a plugin clears the default paths from the include search list. I haven't noticed any other unexpected side effects. I suspect I'm doing something wrong, but wanted to check to see if anyone else has seen this and had a clue what that might be. :slight_smile:

The behavior can be replicated with the PrintHeaderNames example plugin provided with Clang build with "make BUILD_EXAMPLES=1" with a default configured build. The test case I'm using is:
#include <string>

int main() {
}

$~/tools/clang-3.0/bin/clang++ -c test.cxx
$~/tools/clang-3.0/bin/clang++ -cc1 -load Release/lib/libPrintFunctionNames.so -plugin print-fns test.cxx
top-level-decl: "__va_list_tag"
test.cxx:2:10: fatal error: 'string' file not found
#include <string>
          ^
top-level-decl: "__builtin_va_list"
top-level-decl: "main"
1 error generated.
$~/tools/clang-3.0/bin/clang++ -cc1 -load Release/lib/libPrintFunctionNames.so -add-plugin print-fns test.cxx
top-level-decl: "__va_list_tag"
test.cxx:2:10: fatal error: 'string' file not found
#include <string>
          ^
top-level-decl: "__builtin_va_list"
top-level-decl: "main"
1 error generated.
$ ~/tools/clang-3.0/bin/clang++ -cc1 -load Release/lib/libPrintFunctionNames.so test.cxx
test.cxx:2:10: fatal error: 'string' file not found
#include <string>
          ^
1 error generated.

Yours,
Philip Reames

2

No, using clang -cc1 directly does that.

-Eli

3

Try this example plugin:
https://github.com/chisophugis/clang_plugin_example

The script invocation_builder.py assembles the commandline options to the normal clang++ executable so that they get passed down to the plugin correctly and such. That way you get to benefit from the “normal” resolution of header search dirs that clang++ before calling into -cc1.

This is something that I grappled with for a long time, and that was my solution.

4

Thank you for the clarification. I've gotten it working for now.

Is there another way to load a plugin and invoke it which does not undo all the argument parsing/defaults? I suspect that many plugins *want* all the argument parsing the frontend does. I can see some plugins wanting to do their own argument parsing/defaults, but this doesn't seem like the most common case by far. Thoughts?

Yours,
Philip Reames

5

The only way that I know of is to use all that -Xclang mumbo jumbo. Luckily that script takes care of it in a fairly straightforward fashion.

There’s a patch in the works that will simplify all the argument passing and plugin invocation, but I don’t know if it has been accepted yet (or if it even will be accepted).

–Sean Silva