<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 29, 2017, at 12:34 AM, Manuel Klimek <<a href="mailto:klimek@google.com" class="">klimek@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi, thanks for the details design, I'm really looking forward for having this :)<div class=""><br class=""></div><div class="">On a high level, I think this all makes lots of sense. </div><div class="">I have one question about how things get deleted: will record files for headers be deleted at some point, or will they be kept around, and you have to look at all unit files to see whether a given record file is still valid?</div></div></div></blockquote><div><br class=""></div><div>Sorry, I was a bit light on detail in this area. We have a currently unimplemented API in libIndexStore that’s intended to purge unit files whose corresponding main source files no longer exist (e.g. after a .cpp file is renamed) along with any unreferenced record files, but this was more intended as a periodic clean up operation.</div><div><br class=""></div><div>In the current design we expect stale units/records to exist in the store and leave it as the responsibility of the index store client to subscribe to the unit added/removed/modified events in order to track enough information to identify and ignore them, e.g. by maintaining reference counts for each record file. When to actually remove them is also left to the client – the index store just provides APIs for deleting individual records/units.</div><div><br class=""></div><div>Cheers,</div><div>Nathan</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Cheers,</div><div class="">/Manuel<br class=""><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Aug 29, 2017 at 2:18 AM Nathan Hawes <<a href="mailto:nhawes@apple.com" class="">nhawes@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">Hey everyone,<div class=""><br class=""></div><div class="">Xcode 9 shipped with index-while-building functionality based on enhancements to Clang that we’d like to upstream. Key among them is a new option, <font face="Menlo" class="">-index-store-path</font>, that in addition to Clang's usual outputs, causes it to write out indexing data at the supplied path with minimal overhead.</div><div class=""><br class=""></div><div class="">While the current implementation is available at <a href="https://github.com/apple/swift-clang" target="_blank" class="">https://github.com/apple/swift-clang</a>, we’d like to start by getting feedback on the high-level design, which you can read about here: <a href="https://docs.google.com/document/d/1cH2sTpgSnJZCkZtJl1aY-rzy4uGPcrI-6RrUpdATO2Q/edit?usp=sharing" target="_blank" class="">https://docs.google.com/document/d/1cH2sTpgSnJZCkZtJl1aY-rzy4uGPcrI-6RrUpdATO2Q/edit?usp=sharing</a></div><div class=""><br class=""></div><div class="">Please let us know of any concerns, comments or questions you have regarding this feature.</div><div class=""><br class=""></div><div class="">Thanks!</div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">Nathan</div></div></blockquote></div></div>
</div></blockquote></div><br class=""></body></html>