LibTooling and kdev-clang

[Milian Wolff]

On Thursday 28 May 2015 19:00:30 Maciej Poleski wrote:
> 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).

Yes, this sounds good. Depending on the outcome of our other discussion, we 
might not have access to the openDocuments though at all (i.e. if this stuff 
runs in a separate process). In that case, we could simply resort to saving 
all files before running a refactoring step.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150529/4bbd9f04/attachment.sig>