[cfe-dev] zapcc compiler

[Sean Silva]

On Sun, May 24, 2015 at 9:41 AM, Chris Lattner <clattner at apple.com> wrote:

> On May 23, 2015, at 12:25 PM, Yaron Keren <yaron.keren at gmail.com> wrote:
> > zapcc makes distinction between two classes of source files, the
> "system" ones of which all compilation state is kept in memory and the
> "user" ones whose compilation state is removed once compiled. The
> programmer can select which are the "user" files by wildcards set in a
> configuration files. The default of user is .c .cpp .cxx .CC files but it
> could easily be all files in /home/user/yaron or whatever. It is expected
> that the system files are non-changing (such a change will not be
> recognized anyhow until server restart) while the user files are the ones
> to be modified. As an example, you could have
> llvm/lib/MC/MachObjectWriter.cpp as the "user" file so every other file
> compilation result would be kept in memory.
>
> This sounds like a very interesting approach, but also (as you say) very
> complex :-)
>
> Have you looked at the modules work in clang?  It seems that building on
> that infrastructure could help simplify things.  In principle you could
> load “all the modules” and then treat any specific translation unit as a
> filter over the available decls.


This is actually exactly what clang's current modules infrastructure
already does. Submodules are simply a visibility filter on top of the
loaded AST. This is e.g. what the `Hidden` bit on Decl is for:
http://clang.llvm.org/doxygen/classclang_1_1Decl.html#ad58279c91e474c764e418e5a09d32073
(among other places inside clang touched by implementing it this way).

-- Sean Silva


>   This is also, uhm, nontrivial, but building on properly modular headers
> could simplify things a lot.
>
> -Chris
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150526/8587edc1/attachment.html>