LibTooling and kdev-clang

[Maciej Poleski]

Dnia czwartek, 28 maja 2015 15:52:12 piszesz:
> Hey Maciej,
> 
> please send such emails to the kdevelop-devel at kde.org mailing list, so that 
> all others can see what you are doing and chime in as necessary.
> 
> On Wednesday 27 May 2015 22:25:24 Maciej Poleski wrote:
> > Hi
> > 
> > I've just hit very unpleasant impediment. ClangTool contains FileManager,
> > but does not provide way of customizing it. It's trivial but very
> > unpleasant as everything is on place with one tiny exception:
> > http://clang.llvm.org/doxygen/Tooling_8cpp_source.html#l00278
> > 
> > This issue is trivial to fix (example: provide additional optional parameter
> > in constructor - vfs::FileSystem), but even having this fixed upstream now
> > is too late for us.
> > 
> > I see two solutions here:
> >  - Leave default here (flushing KDevelop caches before any refactoring), and
> > customize VFS in place of application of Replacements (yes it is possible
> > here (!) as Rewriter contains SourceManager) which would be used then in
> > tooling::applyAllReplacements - Leave default here (as above), and forget
> > about VFS. Translate Replacements into DocumentChangeSet.
> > 
> > I asked about possible workaround on Clang mailing list, but don't hope for
> > a solution.
> > 
> > Let me know if You have any preferences here.
> 
> Can you give some more context here? What do you want to do exactly, or what 
> is the issue? I just see that ClangTool has a getFiles returning a non-const 
> reference to the FileManager - is that not enough?
> 
> Bye
> 

I wanted to provide custom VFS to libTooling built on top of IDocumentController (and Documents). The purpose is to keep IDocumentController the one way to underlying filesystem instead of accessing source code files directly by libTooling (which may be outdated because of unsaved changes in opened files).
FileManager is "immutable" in sense of FileSystem. There is getVirtualFileSystem() method, but no setter for this property. It seems that making such customization is impossible on FileSystem object (replace whole object using operator= ?).

I discussed this issue on Clang mailing list and I was advised to provide "contents of the files in the tooling interfaces for overlay". Use of this interface (ClangTool::mapVirtualFile) forces preloading content of files into memory. My latest idea is to provide using this interface _only_ already opened documents from IDocumentController (IDocumentController::openDocuments() - hope these are exactly the cached documents), and allow libTooling to read other files directly from filesystem (as these shouldn't be cached anywhere inside KDevelop).

Best Regards
Maciej Poleski