<div dir="ltr"><span style="color:rgb(80,0,80)">On 09/11/2013 02:14 PM, Manuel Klimek wrote:</span><br><div class="gmail_extra"><div class="gmail_quote"><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">
<div class="im"><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">
Yes. This can be rather big, and being able to quickly parse it is<br>
important for interactive use cases.<br></blockquote></div></blockquote><div><br></div><div>That is fair enough. And I agree that it would be wise to limit the proliferation of fields added to this structure to maintain the ability to parse it quickly - I do think however that this very strict parsing could cause problems in the future wrt. extensions both for clang and periphery projects. Perhaps a version field in the next revision?</div>
<div><br></div><div> <br></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"><div class="im"><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">

I'd say that if we really want something more elaborate, we should try to<br>
design it first instead of randomly allowing to add fields in ways that<br>
might later break.<br>
<br>
I'd be curious about other opinions though. (+Edwin, Daniel)<br></blockquote></div></blockquote><div><br></div><div><br></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">
<div class="im"><span style="color:rgb(34,34,34)">On 11 September 2013 23:50, Tobias Grosser </span><span dir="ltr" style="color:rgb(34,34,34)"><<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</a>></span><span style="color:rgb(34,34,34)"> wrote:</span><br>
</div>
I am personally very much in favor of removing this restriction and in fact I proposed it before. This does not mean I propose any extensions today. I agree with Manuel that we should carefully design what we add. Nevertheless, the more released clang versions we have that just abort<br>

on additional keywords, the harder it will be to add backward compatible extensions later on.<br><br></blockquote><div><br></div><div>Ah, slight misunderstanding, I wasn't actually proposing to add the 'target' parameter, rather to simply relax the restriction that clang would reject the file if it encountered unknown fields.</div>
<div><br></div><div>However on reflection given the current behaviour (and as Tobias indicates) it would be very difficult to introduce any new behaviour here without breakage. I doubt the target of my second patch (cmake) would be willing to add breakage here either.</div>
</div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div>My thoughts here are that a compilation database, essential for static analysis purposes, could be very useful in other use cases as well - albeit with some minor additional information.</div>
<div><br></div><div>The build tool that encodes much wisdom in this regard is in a prime position to generate this extra information.</div><div><br></div><div>While it is trivial to then generate this extra information, clang will currently reject the file if I attempt to reuse the JSONCompilationDatabase class to parse the file - and if I parse the file manually, I still lose the ability to reuse other static analysers based on clang.</div>
</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">A future llvm/clang specific use case I can imagine is some application doing whole program analysis. It requires information not only on the individual TUs but also which of those are combined to be analysed as a unit. This sort of information is not currently encoded in the compilation database, and with the current behaviour updates to the build tool generating the file would need to be in lock-step with updates to llvm/clang based analysers consuming it.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"><br></div><div class="gmail_extra">-nick</div></div>