<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 24, 2015 at 9:41 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On May 23, 2015, at 12:25 PM, Yaron Keren <<a href="mailto:yaron.keren@gmail.com">yaron.keren@gmail.com</a>> wrote:<br>
> 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.<br>
<br>
</span>This sounds like a very interesting approach, but also (as you say) very complex :-)<br>
<br>
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.</blockquote><div><br></div><div>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: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__clang.llvm.org_doxygen_classclang-5F1-5F1Decl.html-23ad58279c91e474c764e418e5a09d32073&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=tCV3MPV-y9Y-UI-My4ba711NUInVXp1V1yLRTdm2spQ&s=BwAsHPZpmhMNqUcGcTI8E6_r7rAAIJSVjX5iMhPQw2c&e=">http://clang.llvm.org/doxygen/classclang_1_1Decl.html#ad58279c91e474c764e418e5a09d32073</a> (among other places inside clang touched by implementing it this way).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">  This is also, uhm, nontrivial, but building on properly modular headers could simplify things a lot.<br>
<div class=""><div class="h5"><br>
-Chris<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>