[cfe-users] Redirecting clang tooling errors
Lucas Soltic via cfe-users
cfe-users at lists.llvm.org
Sat Aug 6 04:11:33 PDT 2016
Considering that there is no other viable possibility, for now I have gone with the following:
using llvm::Twine;
using llvm::SmallString;
using llvm::IntrusiveRefCntPtr;
using llvm::MemoryBuffer;
using clang::FileManager;
using clang::PCHContainerOperations;
using clang::FileSystemOptions;
using clang::tooling::ToolInvocation;
using clang::tooling::FileContentMappings;
static std::vector<std::string>
getSyntaxOnlyToolArgs(const Twine &ToolName,
const std::vector<std::string> &ExtraArgs,
StringRef FileName) {
std::vector<std::string> Args;
Args.push_back(ToolName.str());
Args.push_back("-fsyntax-only");
Args.insert(Args.end(), ExtraArgs.begin(), ExtraArgs.end());
Args.push_back(FileName.str());
return Args;
}
bool runToolOnCode(clang::FrontendAction *ToolAction, const Twine &Code,
const Twine &FileName, clang::DiagnosticConsumer& diagConsumer)
{
const std::vector<std::string> args;
const Twine toolName = "clang-tool";
std::shared_ptr<PCHContainerOperations> PCHContainerOps = std::make_shared<PCHContainerOperations>();
const FileContentMappings virtualMappedFiles = FileContentMappings();
SmallString<16> fileNameStorage;
StringRef fileNameRef = FileName.toNullTerminatedStringRef(fileNameStorage);
IntrusiveRefCntPtr<clang::vfs::OverlayFileSystem> OverlayFileSystem
= new clang::vfs::OverlayFileSystem(clang::vfs::getRealFileSystem());
IntrusiveRefCntPtr<clang::vfs::InMemoryFileSystem> inMemoryFileSystem
= new clang::vfs::InMemoryFileSystem;
OverlayFileSystem->pushOverlay(inMemoryFileSystem);
IntrusiveRefCntPtr<FileManager> files(new FileManager(FileSystemOptions(), OverlayFileSystem));
ToolInvocation invocation(getSyntaxOnlyToolArgs(toolName, args, fileNameRef),
ToolAction, files.get(), std::move(PCHContainerOps));
invocation.setDiagnosticConsumer(&diagConsumer);
SmallString<1024> codeStorage;
inMemoryFileSystem->addFile(fileNameRef, 0,
MemoryBuffer::getMemBuffer(Code.toNullTerminatedStringRef(codeStorage)));
for (auto &filenameWithContent : virtualMappedFiles) {
inMemoryFileSystem->addFile(filenameWithContent.first, 0,
MemoryBuffer::getMemBuffer(filenameWithContent.second));
}
return invocation.run();
}
It is basically a copy & past of runToolOnCode() but with the added parameter for diagnostic consumer. In the end it was not too much code to duplicate thanks to ToolInvocation::setDiagnosticConsumer() already existing.
Best regards,
L. Soltic
> Le 4 août 2016 à 20:55, Lucas Soltic via cfe-users <cfe-users at lists.llvm.org> a écrit :
>
> Hello,
>
> I am trying to redirect the output emitted when running a tool through clang::tooling::runToolOnCode() to a buffer or string instead of stderr (llvm::errs()). I'm using clangTooling from release 3.9.
>
> When looking at clangTooling code and following the execution flow, I have found the following:
> clang::tooling::runToolOnCode()
> calls clang::tooling::runToolOnCodeWithArgs()
> which calls clang::tooling::ToolInvocation::run()
> which contains the following :
> TextDiagnosticPrinter DiagnosticPrinter(llvm::errs(), &*DiagOpts);
> DiagnosticsEngine Diagnostics(
> IntrusiveRefCntPtr<clang::DiagnosticIDs>(new DiagnosticIDs()), &*DiagOpts,
> DiagConsumer ? DiagConsumer : &DiagnosticPrinter, false);
>
> So at this point I guess I'm stuck because everything is redirected to stderr…
> Did I miss something or is there really this limitation?
>
> I also thought of redirecting stderr to somewhere else but… I can't see how it will fit my needs as in the end I want to call clang::tooling::runToolOnCode() on different files in parallel, all of it in the same process ; so I'll get stderr mixed with output from several executions. The best solution would obviously being able to provide the DiagnosticConsumer but at the moment everything looks hardcoded.
>
>
> Best regards,
> L. Soltic
>
> _______________________________________________
> cfe-users mailing list
> cfe-users at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20160806/36b05658/attachment.html>
More information about the cfe-users
mailing list