[libTooling] Custom vfs::FileSystem for ClangTool

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).

Is there some place in which FileSystem could be replaced?

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?

Best Regards
Maciej Poleski

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.

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?

Dnia czwartek, 28 maja 2015 08:37:19 piszesz:

> 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.

Best Regards
Maciej Poleski

Dnia czwartek, 28 maja 2015 08:37:19 piszesz:

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?

Dnia czwartek, 28 maja 2015 09:32:04 piszesz:

>
> 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?

Using ClangTool::mapVirtualFile? It is possible but I'm a bit worried about performance in such a case. This would require loading all input files into memory. On big code bases this could be a problem.

Best Regards
Maciej Poleski

Dnia czwartek, 28 maja 2015 09:32:04 piszesz:

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?

Using ClangTool::mapVirtualFile? It is possible but I’m a bit worried about performance in such a case. This would require loading all input files into memory. On big code bases this could be a problem.

I’m doing this in one of the biggest C++ codebases of the world; I can assure you, this is not a performance problem:

  1. the size of the text files is many orders of magnitudes smaller than the size of the produces AST
  2. the time it takes to copy those files is dwarfed by the time it takes to parse them

Dnia czwartek, 28 maja 2015 10:22:24 piszesz:

I'm doing this in one of the biggest C++ codebases of the world; I can
assure you, this is not a performance problem:
1. the size of the text files is many orders of magnitudes smaller than the
size of the produces AST
2. the time it takes to copy those files is dwarfed by the time it takes to
parse them

Good point.

Best Regards
Maciej Poleski