
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Apologies for the delay, Nathan (CC’ed) will be preparing a document describing how it works in detail, and will bring it soon to cfe-dev for discussion.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 9, 2017, at 1:28 PM, Marc-André Laperle <<a href="mailto:marc-andre.laperle@ericsson.com" class="">marc-andre.laperle@ericsson.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div id="divtagdefaultwrapper" dir="ltr" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; font-size: 12pt; font-family: Calibri, Helvetica, sans-serif;" class=""><div dir="ltr" class=""><div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; font-family: Calibri, Helvetica, sans-serif, EmojiFont, 'Apple Color Emoji', 'Segoe UI Emoji', NotoColorEmoji, 'Segoe UI Symbol', 'Android Emoji', EmojiSymbols;" class=""><div style="margin-top: 0px; margin-bottom: 0px;" class="">No concrete plan yet but it's something we'd definitely like to have. I haven't seen in detail how the "indexing while building" is going to work, maybe I missed it? I assume there will be some kind of indexer-agnostic hook in the same spirit of the refactoring work that was proposed. I'll keep an eye on this and make sure our efforts are compatible. In any case, I think there will be enough benefit to warrant major rewrites/refactorings if needed.</div><div style="margin-top: 0px; margin-bottom: 0px;" class=""><br class=""></div><div style="margin-top: 0px; margin-bottom: 0px;" class="">Marc-André<br class=""></div><div style="margin-top: 0px; margin-bottom: 0px;" class=""><br class=""></div></div><hr tabindex="-1" style="display: inline-block; width: 1082.890625px;" class=""><div id="x_divRplyFwdMsg" dir="ltr" class=""><font face="Calibri, sans-serif" style="font-size: 11pt;" class=""><b class="">From:</b><span class="Apple-converted-space"> </span>Benjamin Kramer <<a href="mailto:benny.kra@gmail.com" class="">benny.kra@gmail.com</a>><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Wednesday, August 9, 2017 8:54:03 AM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Marc-André Laperle<br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>via cfe-dev;<span class="Apple-converted-space"> </span><a href="mailto:zeratul976@hotmail.com" class="">zeratul976@hotmail.com</a>; Doug Schaefer; Alex Lorenz; Duncan P. N. Exon Smith; Argyrios Kyrtzidis<br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [cfe-dev] Adding indexing support to Clangd</font><div class=""> </div></div></div><font size="2" class=""><span style="font-size: 10pt;" class=""><div class="PlainText">Awesome, indexing in clangd would be super cool. Do you have a plan on<br class="">how to combine this with the "indexing while building" stuff Apple<br class="">folks are going to contribute? That will be important when we want to<br class="">use clangd with larger projects.<br class=""><br class="">On Tue, Aug 8, 2017 at 7:52 PM, Marc-André Laperle via cfe-dev<br class=""><<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">> Hi!<br class="">><br class="">><br class="">> I want to give a little update on the indexing prototype for Clangd I've<br class="">> been working on. I wanted to share the actual code on Github before I went<br class="">> on vacation but I ran out of time! Sorry about that!<br class="">><br class="">><br class="">> Here's a short summary of the several components there now and what's in<br class="">> progress:<br class="">><br class="">><br class="">> --ClangdIndexStorage--<br class="">><br class="">> malloc-like interface that allocates/frees data blocks of variable sizes on<br class="">> disk. The blocks can contain ints, shorts, strings, pointers (i.e. file<br class="">> offsets), etc. The data is cached in 4K pieces so that local and repeated<br class="">> accesses are all done quickly, in memory.<br class="">><br class="">> Clangd mallocs and writes its index model objects using this.<br class="">><br class="">><br class="">> --BTree--<br class="">><br class="">> A pretty classic BTree implementation. Used to speed up lookup (symbol<br class="">> names, file names). It allocates its nodes using ClangdIndexStorage<br class="">> therefore it is stored on disk. Keys are actually records in<br class="">> ClangdIndexStorage so you can really think of the BTree as a collection of<br class="">> sorted pointers (sorted according to a provided comparator).<br class="">><br class="">><br class="">><br class="">><br class="">> The index model is not very rich yet but the idea is that lower level<br class="">> building blocks (ClangdIndexStorage, BTree) will be there so that we can<br class="">> start iterating.<br class="">><br class="">><br class="">> --ClangdIndexFile--<br class="">><br class="">> Path + information about inclusion in order to be able to represent an<br class="">> include graph.<br class="">><br class="">> The include graph is used to know which files need reindexing for example<br class="">> when a header file changes and also which compilation database entry to use<br class="">> when opening a header in the editor. The first source file including the<br class="">> header file is used to look up the entry in the compilation database. This<br class="">> will also be used for the "Include Browser" feature in the future.<br class="">><br class="">><br class="">> --ClangdIndexSymbol--<br class="">><br class="">> USR + location (pointer to a ClangdIndexFile + start/end offsets)<br class="">><br class="">> This only represents definitions in source files for now. This is part of<br class="">> the indexing-based feature to "Open Definition".<br class="">><br class="">> This is likely to have more changes to represent declaration vs definition,<br class="">> references (Find references feature), call graph, etc.<br class="">><br class="">><br class="">> --ClangdIndex--<br class="">><br class="">> Owns a BTree of ClangdIndexSymbol sorted by USR for fast lookup (used by<br class="">> Open Definition for now). getSymbol(USR) returns a ClangdIndexSymbol.<br class="">><br class="">> Also owns a BTree of ClangdIndexFile sorted by Path for fast lookup. As<br class="">> explained above, used to find proper compilation database entry and to react<br class="">> to header changes. getFile(Path) returns a ClangdIndexFile.<br class="">><br class="">><br class="">> # Building the index<br class="">><br class="">><br class="">> When Clangd gets the initialize request from the client, it is given a<br class="">> rootURI. It starts indexing each source files under this root, creating<br class="">> ClangdIndexFiles and ClangdIndexSymbols. This is done with the help of<br class="">> index::IndexDataConsumer.<br class="">><br class="">><br class="">> At the moment, the main covered scenarios are building the index from<br class="">> scratch and adding files. Support for modifying files and removing them is<br class="">> not fully implemented yet (but this is a must of course!).<br class="">><br class="">><br class="">> In case you are wondering, there is no fancy caching of headers or preamble<br class="">> used while indexing, so the process is quite slow. I have been focusing on<br class="">> the model and persistence of the index versus the input (parsing). This will<br class="">> have to be addressed too.<br class="">><br class="">><br class="">> # Examples of using the index<br class="">><br class="">><br class="">> When the user does the "Open Declaration" command, it retrieves the<br class="">> ClangdIndexSymbol from the ClangdIndex using the USR at the requested offset<br class="">> (sped up by the BTree). The location of the ClangdIndexSymbol (if found) is<br class="">> then returned to the editor.<br class="">><br class="">><br class="">> When the user opens a header file, it retrieves the ClangdIndexFile from the<br class="">> ClangdIndex using the path of the header (sped up by the BTree). Then it<br class="">> recursively finds which file includes it until there is no more, at this<br class="">> point chances are that this is a source file. Use this source file path to<br class="">> find a potential entry in the compilation database (so that we gets proper<br class="">> compiler flags, etc).<br class="">><br class="">><br class="">><br class="">><br class="">><br class="">> This is just to give you a taste of what I have in mind and what kind of<br class="">> progress is being made. I'd like to have the "lower-level" parts ready for<br class="">> review soon after I come back from vacation (Aug 24th). I was thinking that<br class="">> ClangdIndexStorage and BTree can go in first as they are quite isolated and<br class="">> unit-testable. The rest of the code will also be available on Github to show<br class="">> more concrete usage of them if necessary.<br class="">><br class="">><br class="">> Regards,<br class="">><br class="">> Marc-André<br class="">><br class="">> ________________________________<br class="">> From: cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" class="">cfe-dev-bounces@lists.llvm.org</a>> on behalf of Vladimir<br class="">> Voskresensky via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>><br class="">> Sent: Thursday, June 1, 2017 3:10:55 PM<br class="">> To:<span class="Apple-converted-space"> </span><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">><br class="">> Subject: Re: [cfe-dev] Adding indexing support to Clangd<br class="">><br class="">><br class="">><br class="">><br class="">> On 06/ 1/17 06:26 PM, Ilya Biryukov via cfe-dev wrote:<br class="">><br class="">> Other IDEs do that very similarly to CDT, AFAIK. Compromising correctness,<br class="">> but getting better performance.<br class="">> Reusing modules would be nice, and I wonder if it could also be made<br class="">> transparent to the users of the tool (i.e. we could have an option 'pretend<br class="">> these headers are modules every time you encounter them')<br class="">> I would expect that to break on most projects, though. Not sure if people<br class="">> would be willing to use something that spits tons of errors on them.<br class="">> Interesting direction for prototyping...<br class="">><br class="">> As Doug mentioned, surprisingly the tricks with headers in the majority of<br class="">> projects give pretty good results :-)<br class="">><br class="">> In NetBeans we have similar to CDT headers caching approach.<br class="">><br class="">> The only difference is that when we hit #include the second time we only<br class="">> check if we can skip indexing,<br class="">> But we always do "fair lightweight preprocessing" to keep fair context of<br class="">> all possible inner #ifdef/#else/#define directives (because they might<br class="">> affect the current file).<br class="">> For that we use APT (Abstract Preprocessor Tree) per-file which is constant<br class="">> for the file and is created once - similar to clang's PTH (Pre-Tokenized<br class="">> headers).<br class="">><br class="">> Visiting file's APT we can produce different output based on input<br class="">> preprocessor state.<br class="">> It can be visited in "light" mode or "produce tokens" mode, but it is always<br class="">> gives correct result from the strict compiler point of view.<br class="">> We also do indexing in parallel and the APT (being immutable) is easily<br class="">> shared by index-visitors from all threads.<br class="">> Btw stat cache is also reused from all indexing threads with appropriate<br class="">> synchronizations.<br class="">><br class="">> So in NetBeans we observe that using this tricks (which really looks like<br class="">> multi-modules per header file) the majority of projects are in very good<br class="">> accuracy + I can also confirm that it gives ~10x speedup.<br class="">><br class="">> Hope it helps,<br class="">> Vladimir.<br class="">><br class="">><br class="">> On Thu, Jun 1, 2017 at 5:14 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:<br class="">>><br class="">>> Not sure this has already been discussed, but would it be<br class="">>> practical/reasonable to use Clang's modules support for this? Might keep the<br class="">>> implementation much simpler - and perhaps provide an extra incentive for<br class="">>> users to modularize their build/code which would help their actual build<br class="">>> tymes (& heck, parsed modules could even potentially be reused between<br class="">>> indexer and final build - making apparent build times /really/ fast)<br class="">>><br class="">>> On Thu, Jun 1, 2017 at 8:12 AM Doug Schaefer via cfe-dev<br class="">>> <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">>>><br class="">>>> I thought I’d chip in and describe Eclipse CDT’s strategy with header<br class="">>>> caching. It’s actually a big cheat but the results have proven to be pretty<br class="">>>> good.<br class="">>>><br class="">>>> CDT’s hack actually starts in the preprocessor. If we see a header file<br class="">>>> has already been indexed, we skip including it. At the back end, we<br class="">>>> seamlessly use the index or the current symbol table when doing symbol<br class="">>>> lookup. Symbols that get missed because we skipped header files get picked<br class="">>>> up out of the index instead. We also do that in the preprocessor to look up<br class="">>>> missing macros out of the index when doing macro substitution.<br class="">>>><br class="">>>> The performance gains were about an order of magnitude and it magically<br class="">>>> works most of the time with the main issue being header files that get<br class="">>>> included multiple times affected by different macro values but the effects<br class="">>>> of that haven’t been major.<br class="">>>><br class="">>>> With clang being a real compiler, I had my doubts that you could even do<br class="">>>> something like this without adding hooks in places the front-end gang might<br class="">>>> not like. Love to be proven wrong. It really is very hard to keep up with<br class="">>>> the evolving C++ standard and we could sure use the help clangd could offer.<br class="">>>><br class="">>>> Hope that helps,<br class="">>>> Doug.<br class="">>>><br class="">>>> From: cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" class="">cfe-dev-bounces@lists.llvm.org</a>> on behalf of Ilya Biryukov<br class="">>>> via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>><br class="">>>> Reply-To: Ilya Biryukov <<a href="mailto:ibiryukov@google.com" class="">ibiryukov@google.com</a>><br class="">>>> Date: Thursday, June 1, 2017 at 10:52 AM<br class="">>>> To: Vladimir Voskresensky <<a href="mailto:vladimir.voskresensky@oracle.com" class="">vladimir.voskresensky@oracle.com</a>><br class="">>>> Cc: via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>><br class="">>>><br class="">>>> Subject: Re: [cfe-dev] Adding indexing support to Clangd<br class="">>>><br class="">>>> Thanks for the insights, I think I get the gist of the idea with the<br class="">>>> "module" PCH.<br class="">>>> One question is: what if the system headers are included after the user<br class="">>>> includes? Then we abandon the PCH cache and run the parsing from scratch,<br class="">>>> right?<br class="">>>><br class="">>>> FileSystemStatCache that is reused between compilation units? Sounds like<br class="">>>> a low-hanging fruit for indexing, thanks.<br class="">>>><br class="">>>> On Thu, Jun 1, 2017 at 11:52 AM, Vladimir Voskresensky<br class="">>>> <<a href="mailto:vladimir.voskresensky@oracle.com" class="">vladimir.voskresensky@oracle.com</a>> wrote:<br class="">>>>><br class="">>>>> Hi Ilia,<br class="">>>>><br class="">>>>> Sorry for the late reply.<br class="">>>>> Unfortunately mentioned hacks were done long time ago and I couldn't<br class="">>>>> find the changes at the first glance :-(<br class="">>>>><br class="">>>>> But you can think about reusable chaned PCHs in the "module" way.<br class="">>>>> Each system header is a module.<br class="">>>>> There are special index_headers.c and index_headers.cpp files which<br class="">>>>> includes all standard headers.<br class="">>>>> These files are indexed first and create "module" per #include.<br class="">>>>> Module is created once or several times if preprocessor contexts are<br class="">>>>> very different like C vs. C++98 vs. C++14.<br class="">>>>> Then reused.<br class="">>>>> Of course it could compromise the accuracy, but for proof of concept was<br class="">>>>> enough to see that expected indexing speed can be achieved theoretically.<br class="">>>>><br class="">>>>> Btw, another hint: implementing FileSystemStatCache gave the next<br class="">>>>> visible speedup. Of course need to carefully invalidate/update it when file<br class="">>>>> was modified in IDE or externally.<br class="">>>>> So, finally we got just 2x slowdown, but the accuracy of "real"<br class="">>>>> compiler. And then as you know we have started Clank :-)<br class="">>>>><br class="">>>>> Hope it helps,<br class="">>>>> Vladimir.<br class="">>>>><br class="">>>>><br class="">>>>> On 29.05.2017 11:58, Ilya Biryukov wrote:<br class="">>>>><br class="">>>>> Hi Vladimir,<br class="">>>>><br class="">>>>> Thanks for sharing your experience.<br class="">>>>><br class="">>>>>> We did such measurements when evaluated clang as a technology to be<br class="">>>>>> used in NetBeans C/C++, I don't remember the exact absolute numbers now, but<br class="">>>>>> the conclusion was:<br class="">>>>>><br class="">>>>>> to be on par with the existing NetBeans speed we have to use different<br class="">>>>>> caching, otherwise it was like 10 times slower.<br class="">>>>><br class="">>>>> It's a good reason to focus on that issue from the very start than.<br class="">>>>> Would be nice to have some exact measurements, though. (i.e. on LLVM).<br class="">>>>> Just to know how slow exactly was it.<br class="">>>>><br class="">>>>>> +1. Btw, may be It is worth to set some expectations what is available<br class="">>>>>> during and after initial index phase.<br class="">>>>>> I.e. during initial phase you'd probably like to have navigation for<br class="">>>>>> file opened in editor and can work in functions bodies.<br class="">>>>><br class="">>>>> We definitely want diagnostics/completions for the currently open file<br class="">>>>> to be available. Good point, we definitely want to explicitly name the<br class="">>>>> available features in the docs/discussions.<br class="">>>>><br class="">>>>>> As to initial indexing:<br class="">>>>>> Using PTH (not PCH) gave significant speedup.<br class="">>>>>><br class="">>>>>> Skipping bodies gave significant speedup, but you miss the references<br class="">>>>>> and later have to reindex bodies on demand.<br class="">>>>>> Using chainged PCH gave the next visible speedup.<br class="">>>>>><br class="">>>>>> Of course we had to made some hacks for PCHs to be more often<br class="">>>>>> "reusable" (comparing to strict compiler rule) and keep multiple versions.<br class="">>>>>> In average 2: one for C and one for C++ parse context.<br class="">>>>>> Also there is a difference between system headers and projects headers,<br class="">>>>>> so systems' can be cached more aggressively.<br class="">>>>><br class="">>>>> Is this work open-source? The interesting part is how to "reuse" the PCH<br class="">>>>> for a header that's included in a different order.<br class="">>>>> I.e. is there a way to reuse some cached information(PCH, or anything<br class="">>>>> else) for <map> and <vector> when parsing these two files:<br class="">>>>> ```<br class="">>>>> // foo.cpp<br class="">>>>> #include <vector><br class="">>>>> #include <map><br class="">>>>> ...<br class="">>>>><br class="">>>>> // bar.cpp<br class="">>>>> #include <map><br class="">>>>> #include <vector><br class="">>>>> ....<br class="">>>>> ```<br class="">>>>><br class="">>>>> --<br class="">>>>> Regards,<br class="">>>>> Ilya Biryukov<br class="">>>>><br class="">>>>><br class="">>>><br class="">>>><br class="">>>><br class="">>>> --<br class="">>>> Regards,<br class="">>>> Ilya Biryukov<br class="">>>><br class="">>>> _______________________________________________<br class="">>>> cfe-dev mailing list<br class="">>>><span class="Apple-converted-space"> </span><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">>>><span class="Apple-converted-space"> </span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" id="LPlnk18095" previewremoved="true" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><div id="LPBorder_GT_15023101281470.536794747968749" style="margin-bottom: 20px; overflow: auto; width: 1105px; text-indent: 0px;" class=""><table id="LPContainer_15023101281400.34573586880836815" role="presentation" cellspacing="0" style="width: 994.5px; background-color: rgb(255, 255, 255); position: relative; overflow: auto; padding-top: 20px; padding-bottom: 20px; margin-top: 20px; border-top-width: 1px; border-top-style: dotted; border-top-color: rgb(200, 200, 200); border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: rgb(200, 200, 200);" class=""><tbody class=""><tr valign="top" style="border-spacing: 0px;" class=""><td id="TextCell_15023101281410.39054641597455775" colspan="2" style="vertical-align: top; position: relative; padding: 0px; display: table-cell;" class=""><div id="LPRemovePreviewContainer_15023101281410.346837753144559" class=""></div><div id="LPExpandDescriptionContainer_15023101281410.5420088185176481" class=""></div><div id="LPTitle_15023101281410.30416124038236547" style="top: 0px; color: rgb(210, 71, 38); font-weight: 400; font-size: 21px; font-family: wf_segoe-ui_light, 'Segoe UI Light', 'Segoe WP Light', 'Segoe UI', 'Segoe WP', Tahoma, Arial, sans-serif; line-height: 21px;" class=""><a id="LPUrlAnchor_15023101281420.2734156092277834" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" style="text-decoration: none;" class="">cfe-dev -- Clang Front End for LLVM Developers' List</a></div><div id="LPMetadata_15023101281420.06094032275510297" style="margin: 10px 0px 16px; color: rgb(102, 102, 102); font-weight: 400; font-family: wf_segoe-ui_normal, 'Segoe UI', 'Segoe WP', Tahoma, Arial, sans-serif; font-size: 14px; line-height: 14px;" class=""><a href="http://lists.llvm.org/" class="">lists.llvm.org</a></div><div id="LPDescription_15023101281420.1588345157282115" altdesc="Subscribe to cfe-dev by filling out the following form. You will be sent email requesting confirmation, to prevent others from gratuitously subscribing you. This is a hidden list, which means that the list of members is available only to the list administrator.<br/><br/>If you choose not to enter a password, one will be automatically generated for you, and it will be sent to you once you've confirmed your subscription. You can always request a mail-back of your password when you edit your personal options. Once a month, your password will be emailed to you as a reminder." style="display: block; color: rgb(102, 102, 102); font-weight: 400; font-family: wf_segoe-ui_normal, 'Segoe UI', 'Segoe WP', Tahoma, Arial, sans-serif; font-size: 14px; line-height: 20px; max-height: 100px; overflow: hidden;" class="">To see the collection of prior postings to the list, visit the cfe-dev Archives. Using cfe-dev: To post a message to all the list members, send email ...</div></td></tr></tbody></table></div><br class="">><br class="">><br class="">><br class="">><br class="">> --<br class="">> Regards,<br class="">> Ilya Biryukov<br class="">><br class="">><br class="">> _______________________________________________<br class="">> cfe-dev mailing list<br class="">><span class="Apple-converted-space"> </span><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">><span class="Apple-converted-space"> </span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" id="LPlnk966284" previewremoved="true" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><div id="LPBorder_GT_15023101282430.36100010322394005" style="margin-bottom: 20px; overflow: auto; width: 1105px; text-indent: 0px;" class=""><table id="LPContainer_15023101282400.8055970851259272" role="presentation" cellspacing="0" style="width: 994.5px; background-color: rgb(255, 255, 255); position: relative; overflow: auto; padding-top: 20px; padding-bottom: 20px; margin-top: 20px; border-top-width: 1px; border-top-style: dotted; border-top-color: rgb(200, 200, 200); border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: rgb(200, 200, 200);" class=""><tbody class=""><tr valign="top" style="border-spacing: 0px;" class=""><td id="TextCell_15023101282400.9256702177355222" colspan="2" style="vertical-align: top; position: relative; padding: 0px; display: table-cell;" class=""><div id="LPRemovePreviewContainer_15023101282400.018914313479271416" class=""></div><div id="LPExpandDescriptionContainer_15023101282410.49316242953165557" class=""></div><div id="LPTitle_15023101282410.7171356269266411" style="top: 0px; color: rgb(210, 71, 38); font-weight: 400; font-size: 21px; font-family: wf_segoe-ui_light, 'Segoe UI Light', 'Segoe WP Light', 'Segoe UI', 'Segoe WP', Tahoma, Arial, sans-serif; line-height: 21px;" class=""><a id="LPUrlAnchor_15023101282410.9298549292629085" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" style="text-decoration: none;" class="">cfe-dev -- Clang Front End for LLVM Developers' List</a></div><div id="LPMetadata_15023101282410.8562499700525248" style="margin: 10px 0px 16px; color: rgb(102, 102, 102); font-weight: 400; font-family: wf_segoe-ui_normal, 'Segoe UI', 'Segoe WP', Tahoma, Arial, sans-serif; font-size: 14px; line-height: 14px;" class=""><a href="http://lists.llvm.org/" class="">lists.llvm.org</a></div><div id="LPDescription_15023101282410.4362496879162233" altdesc="Subscribe to cfe-dev by filling out the following form. You will be sent email requesting confirmation, to prevent others from gratuitously subscribing you. This is a hidden list, which means that the list of members is available only to the list administrator.<br/><br/>If you choose not to enter a password, one will be automatically generated for you, and it will be sent to you once you've confirmed your subscription. You can always request a mail-back of your password when you edit your personal options. Once a month, your password will be emailed to you as a reminder." style="display: block; color: rgb(102, 102, 102); font-weight: 400; font-family: wf_segoe-ui_normal, 'Segoe UI', 'Segoe WP', Tahoma, Arial, sans-serif; font-size: 14px; line-height: 20px; max-height: 100px; overflow: hidden;" class="">To see the collection of prior postings to the list, visit the cfe-dev Archives. Using cfe-dev: To post a message to all the list members, send email ...</div></td></tr></tbody></table></div><br class="">><br class="">><br class="">><br class="">> _______________________________________________<br class="">> cfe-dev mailing list<br class="">><span class="Apple-converted-space"> </span><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">><span class="Apple-converted-space"> </span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" id="LPlnk550609" previewremoved="true" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><div id="LPBorder_GT_15023101290640.8889947713721321" style="margin-bottom: 20px; overflow: auto; width: 1105px; text-indent: 0px;" class=""><table id="LPContainer_15023101290620.8067476930338331" role="presentation" cellspacing="0" style="width: 994.5px; background-color: rgb(255, 255, 255); position: relative; overflow: auto; padding-top: 20px; padding-bottom: 20px; margin-top: 20px; border-top-width: 1px; border-top-style: dotted; border-top-color: rgb(200, 200, 200); border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: rgb(200, 200, 200);" class=""><tbody class=""><tr valign="top" style="border-spacing: 0px;" class=""><td id="TextCell_15023101290620.9796603798313431" colspan="2" style="vertical-align: top; position: relative; padding: 0px; display: table-cell;" class=""><div id="LPRemovePreviewContainer_15023101290620.020559812140527267" class=""></div><div id="LPExpandDescriptionContainer_15023101290620.07515647179033214" class=""></div><div id="LPTitle_15023101290620.8071502854096299" style="top: 0px; color: rgb(210, 71, 38); font-weight: 400; font-size: 21px; font-family: wf_segoe-ui_light, 'Segoe UI Light', 'Segoe WP Light', 'Segoe UI', 'Segoe WP', Tahoma, Arial, sans-serif; line-height: 21px;" class=""><a id="LPUrlAnchor_15023101290630.6745953169364899" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" style="text-decoration: none;" class="">cfe-dev -- Clang Front End for LLVM Developers' List</a></div><div id="LPMetadata_15023101290630.16021381641462962" style="margin: 10px 0px 16px; color: rgb(102, 102, 102); font-weight: 400; font-family: wf_segoe-ui_normal, 'Segoe UI', 'Segoe WP', Tahoma, Arial, sans-serif; font-size: 14px; line-height: 14px;" class=""><a href="http://lists.llvm.org/" class="">lists.llvm.org</a></div><div id="LPDescription_15023101290630.15000156895763628" altdesc="Subscribe to cfe-dev by filling out the following form. You will be sent email requesting confirmation, to prevent others from gratuitously subscribing you. This is a hidden list, which means that the list of members is available only to the list administrator.<br/><br/>If you choose not to enter a password, one will be automatically generated for you, and it will be sent to you once you've confirmed your subscription. You can always request a mail-back of your password when you edit your personal options. Once a month, your password will be emailed to you as a reminder." style="display: block; color: rgb(102, 102, 102); font-weight: 400; font-family: wf_segoe-ui_normal, 'Segoe UI', 'Segoe WP', Tahoma, Arial, sans-serif; font-size: 14px; line-height: 20px; max-height: 100px; overflow: hidden;" class="">To see the collection of prior postings to the list, visit the cfe-dev Archives. Using cfe-dev: To post a message to all the list members, send email ...</div></td></tr></tbody></table></div><br class="">><br class=""></div></span></font></div></div></blockquote></div><br class=""></body></html>