<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 01.03.2013, at 17:15, Denis Steckelmacher wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255); font-family: arial, helvetica, sans-serif; font-size: 12pt; position: static; z-index: auto; "><div><br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial,helvetica,sans-serif; background-color: transparent; font-style: normal;">This remark brings me to the second point : avoiding re-parsing files. I don't know sufficiently well the Clang's internals, but is it possible for Clang to parse a header and to keep in memory a pre-parsed AST for it ? If this AST is a complete one (with every included files expanded inline), updating an included file will force Clang to rebuild the AST, but it is already the case for
precompiled headers. Having these ASTs in memory and using them every time a file is included could give a fair speedup to the compilation process.</div></div></div></blockquote></div><br><div>Hi,</div><div><br></div><div>Just responding to a small part of your mail. It is easily possible for Clang to keep a pre-parsed AST for a header in memory, but that's not quite enough. There is some internal state in other parts (particularly Sema) that also needs to reflect the code parsed so far.</div><div>Our precompiled header machinery can actually fully restore the compiler state, of course.</div><div>The other issue is the same one that affects PCH. Header files are order-dependent. If the header state isn't an exact prefix of the compilation unit, its incorrect to use it. Some coding conventions thus make PCH very hard to use - LLVM's own convention of putting the primary header as the first thing in the file, for example, makes PCH pretty much useless.</div><div><br></div><div>Sebastian</div></body></html>