[cfe-dev] [libTooling] Custom vfs::FileSystem for ClangTool

[Manuel Klimek]

On Thu, May 28, 2015 at 11:22 AM Maciej Poleski <poleski.maciej at gmail.com>
wrote:

> Dnia czwartek, 28 maja 2015 08:37:19 piszesz:
> > On Wed, May 27, 2015 at 10:56 PM Maciej Poleski <
> poleski.maciej at gmail.com>
> > wrote:
> >
> > > Hi
> > >
> > > I'm looking for some way to customize FileSystem object used by
> ClangTool
> > > (especially in ClangTool::run). This is almost nice:
> > > http://clang.llvm.org/doxygen/Tooling_8cpp_source.html#l00278
> > > almost, because object is created by implementation without chance to
> > > change this behavior (provide my own implementation).
> > >
> >
> > Which object?
> >
> > If you want to inject files, you can currently do that.
>
> My own subclass of vfs::FileSystem (or the whole FileManager).
> FileManager is initialized in constructor of ClangTool to "new
> FileManager(FileSystemOptions())". I want to provide optional second
> argument to constructor of FileManager.
>
> >
> >
> > > Is there some place in which FileSystem could be replaced?
> > >
> >
> > Currently not.
> >
> > I also seen this way of "consuming AST":
> > >
> > >
> http://eli.thegreenplace.net/2012/06/08/basic-source-to-source-transformation-with-clang/
> > > but it's quite old example, and looks "slightly" different than current
> > > implementation of ClangTool::run (with its use of ToolInvocation and
> > > others).
> > >
> > > Is there some general solution of this problem?
> > >
> >
> > Which problem exactly?
> >
>
> The general problem is that I have some file system abstraction in IDE
> (KDevelop - DocumentController) and want to provide custom VFS on top of
> this abstraction for Tooling (possibly ClangTool). This would make file
> accesses from Clang be consistent with IDE accesses.
>

And you're saying it's not possible to set that up by providing the
contents of the files in the tooling interfaces for overlay? Can you expand
on why?


>
> Best Regards
> Maciej Poleski
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150528/5bd41c55/attachment.html>