Driver/Libtooling: Clang can’t seem to find C++ system include directories

[Sirraide]

I can’t seem to figure out how to get Clang to add C++ system include directories to the include path. I’m not sure this really counts as an issue (I’ve also already tried asking in the #libtooling channel on the LLVM Discord server, and so far, we haven’t been able to find an answer to this).

Essentially, I want to take some C++ code that includes C++ stdlib headers (e.g. #include <cstdlib>), parse it, and then do something with the resulting ASTContext. I started out trying to run a frontend action on it via runToolOnCode, but that doesn’t seem to add any include directories.

Next, I tried using clang::ASTUnit::LoadFromCompilerInvocation to create an ASTContext from a CompilerInvocation, which I managed to obtain in one of three ways:

• Calling clang::CompilerInvocation::CreateFromArgs,
• Creating a clang::driver::Driver, using that to create a Compilation, extracting the arguments from that compilation, calling AddClangCXXStdlibIncludeArgs on the tool chain that that compilation gives me, presumably to add the include paths that I’m looking for, and finally passing all of those arguments to clang::CompilerInvocation::CreateFromArgs,
• Calling clang::createInvocation.

So far, while the latter two approaches do manage to pull in some system headers (e.g. it manages to find stdlib.h), it still can’t seem to find any C++ system headers (e.g. <cstdlib>).

It would be helpful to know what the ‘proper’ way of accomplishing any of this is; I can, of course, add the include paths manually as command-line arguments to any of the three approaches mentioned above, but doing so 1. becomes rather untenable once different platforms are involved, and 2. seems rather janky seeing as Clang knows what the right include directories are (after all, it never fails to find them when I try and run clang foo.cc from the terminal), and it seems like a bad idea to try and do that manually when some part of Clang already knows how to do that.

So, to summarise, all I would like to be able to do is take some C++ code as a string and get an ASTContext from it that I can work with, and I want clang to behave in pretty much exactly the same manner as though I had run it from the terminal.

Not sure how much this helps, but I’m running Fedora 39.

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: None (Sirraide)

I can’t seem to figure out how to get Clang to add C++ system include directories to the include path. I’m not sure this really counts as an issue (I’ve also already tried asking in the #libtooling channel on the LLVM Discord server, and so far, we haven’t been able to find an answer to this).

Essentially, I want to take some C++ code that includes C++ stdlib headers (e.g. #include <cstdlib>), parse it, and then do something with the resulting ASTContext. I started out trying to run a frontend action on it via runToolOnCode, but that doesn’t seem to add any include directories.

Next, I tried using clang::ASTUnit::LoadFromCompilerInvocation to create an ASTContext from a CompilerInvocation, which I managed to obtain in one of three ways:

• Calling clang::CompilerInvocation::CreateFromArgs,
• Creating a clang::driver::Driver, using that to create a Compilation, extracting the arguments from that compilation, calling AddClangCXXStdlibIncludeArgs on the tool chain that that compilation gives me, presumably to add the include paths that I’m looking for, and finally passing all of those arguments to clang::CompilerInvocation::CreateFromArgs,
• Calling clang::createInvocation.

So far, while the latter two approaches do manage to pull in some system headers (e.g. it manages to find stdlib.h), it still can’t seem to find any C++ system headers (e.g. <cstdlib>).

It would be helpful to know what the ‘proper’ way of accomplishing any of this is; I can, of course, add the include paths manually as command-line arguments to any of the three approaches mentioned above, but doing so 1. becomes rather untenable once different platforms are involved, and 2. seems rather janky seeing as Clang knows what the right include directories are (after all, it never fails to find them when I try and run clang foo.cc from the terminal), and it seems like a bad idea to try and do that manually when some part of Clang already knows how to do that.

So, to summarise, all I would like to be able to do is take some C++ code as a string and get an ASTContext from it that I can work with, and I want clang to behave in pretty much exactly the same manner as though I had run it from the terminal.

Not sure how much this helps, but I’m running Fedora 39.

[HighCommander4]

Could you share a complete source code listing of the attempt with createInvocation()?

[Sirraide]

Could you share a complete source code listing of the attempt with createInvocation()?

These seem to be the relevant parts:

static constexpr const char* args[] = {
    clang_path, // Tried `/usr/bin/clang` as well as a local build.
    //"-###",
    "cxx_headers.cc",
    "-std=c++2b",
    "-Wall",
    "-Wextra",
    "-Werror=return-type",
    "-Wno-unused",
    "-fwrapv",
    "-fcolor-diagnostics",
    "-fsyntax-only"
};

clang::CreateInvocationOptions opts;
opts.VFS = vfs;
opts.Diags = &clang.getDiagnostics(); // `clang` is a `clang::CompilerInstance`
std::shared_ptr<clang::CompilerInvocation> I = clang::createInvocation(args, opts);
auto AST = clang::ASTUnit::LoadFromCompilerInvocation(
    I,
    std::make_shared<clang::PCHContainerOperations>(),
    clang.getDiagnosticsPtr(),
    &clang.getFileManager()
);

[HighCommander4]

I was hoping for something I could copy-paste and build to try out the behaviour locally :) I don't usually write stand-alone tools, so I'd have to do additional research into things like how to create a CompilerInstance.

[Sirraide]

I was hoping for something I could copy-paste and build to try out the behaviour locally :) I don't usually write stand-alone tools, so I'd have to do additional research into things like how to create a CompilerInstance.

I see. Here’s how I’m creating one (though don’t ask me whether that’s how you’re supposed to do it or not):

using OFS = llvm::vfs::OverlayFileSystem;
clang::CompilerInstance clang;
llvm::IntrusiveRefCntPtr<OFS> overlay = 
    std::make_unique<OFS>(llvm::vfs::getRealFileSystem());
llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem> vfs = 
    std::make_unique<llvm::vfs::InMemoryFileSystem>();
overlay->pushOverlay(vfs);

clang.createDiagnostics();
clang.getTargetOpts().Triple = llvm::sys::getDefaultTargetTriple();
clang.createTarget();
clang.createSourceManager(*clang.createFileManager(overlay));

I can try and put together a self-contained executable if that would help, but currently, all of this is a bit all over the place in my code base...

[HighCommander4]

Thanks, that seems to be enough to go on.

I turned your code snippets into a standalone program, and I'm seeing the same behaviour you are, which suggests the issue likely isn't related to your environment, but some sort of missing setup step.

I stepped through the driver code and traced the issue down to this early return. That's what I was hoping my suggestion on Discord about building with -DGCC_INSTALL_PREFIX would fix, but it doesn't for me either.

[HighCommander4]

Seems to be related to your use of VFS APIs.

It's trying the right prefixes (e.g. /usr), but then the VFS.exists(Prefix) check here fails.

I assume you can take it from here, but let me know if you need me to investigate the VFS part more.

[Sirraide]

I stepped through the driver code and traced the issue down to [this early return]

Oh yeah, I forgot about that, my bad. I also ran into that and was going to mention it, but I ended up forgetting about it. Good to know that I’m not the only one who’s run into this though.

[Sirraide]

Update: I think the issue might have something to do with me using an overlay file system; if I don’t specify a filesystem and pass in a path to a file on disk, everything seems to work correctly

[Sirraide]

It would seem the problem was, at least in part, between keyboard and chair: I accidentally set the in-memory filesystem as the VFS for the CreateInvocationOptions instead of the overlay filesystem, so obviously, it wasn’t finding anything... if I specify the latter, everything works. I suppose I was just so used to include paths not being present from my history with runToolOnCode that I didn’t even stop to consider that the filesystem not being set correctly might be the issue.

It seems the answer to my question, then, is that the ‘proper’ way of doing this is indeed to use clang::createInvocation; I would maybe suggest documenting that somewhere so the next person that wants to parse some C++ doesn’t have to deal with all of this all over again, because, correct me if I’m wrong, but I don’t think any of the official examples or documentation (or SO posts etc.) that I managed to find mention this function (I don’t think I would have found it had it not been for @HighCommander4 pointing it out to me)—assuming of course that this really is the intended way of doing this, but it does seem to be the most straight-forward option from what I can tell.

I’d be more than happy to document this myself provided someone can direct me as to where I should put that. :)

Lastly, is there anything we want to do wrt debugging path resolution here? Because if, say, there was some debugging cl option that made the driver print out the directories it tried and you then got a message that said something along the lines of ‘/usr does not exist’, then it would probably become pretty clear that the issue is the filesystem. I could look into adding something like that too if there is any interest in that.

[HighCommander4]

Glad you got it figured out!

I'll leave it to folks who know more about the driver than I do, to comment on your questions about documentation and debugging options.