On Thu, Feb 13, 2014 at 12:49 AM, Douglas Gregor <[email protected]> wrote:
> > On Feb 12, 2014, at 3:45 PM, Rafael Espíndola <[email protected]> > wrote: > > >> I have no idea what you mean by “clang process”. You don’t actually > mean the whole process itself, because FS isn’t thread-safe and therefore > isn’t some kind of global singleton. Plus, different invocations of the > compiler may have different FS, so making this a global singleton is > completely wrong . Any thread-specific “singleton” would be wrong for the > same reasons. > >> > >> I guess we could toss the responsibility for managing the FS instance > up to “the client”, but which clients are those? Some clients will want to > pre-populate and widely share a FS, while others just want > CompilerInvocation to create the FS if the command-line arguments passed > through to it require the FS. We want to support the former without > complicating the latter. IntrusiveRefCntPtr makes that easy to do with > completely acceptable overhead. > > > > OK, if that is the use case, then I agree with IntrusiveRefCntPtr, but > > that means I misunderstood how the FS is to be used. > > > > My understanding was that the FS would always be shared, so that it > > could be constructed once as close to main as possible. Would you mind > > explaining when we would want two different FS alive in the same > > process (or thread)? > > The FS can be created by passing a not-yet-implemented “-vfs <file>” > argument to Clang, which will allocate and populate a virtual file system > based on the input file. If I were writing a Clang compiler server, I > wouldn’t want to share the virtual file systems of distinct Clang > invocations. > Just +1'ing this comment, as it's a really important use case for us :) > > > Now I realize that maybe I just missed that this is to be exposed via > > libclang and we can assume nothing about how the clients want to use > > FS? > > > VFS file creation routines will be exposed by libclang. That’s one of the > clients… an IDE that has edited files in memory that it doesn’t want to > flush to disk before invoking Clang. > > - Doug > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
