[cfe-dev] JSONCompilationDatabase additional keys

[Nicholas Gill]

On 09/11/2013 02:14 PM, Manuel Klimek wrote:

> Yes. This can be rather big, and being able to quickly parse it is
>> important for interactive use cases.
>>
>
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?



> I'd say that if we really want something more elaborate, we should try to
>> design it first instead of randomly allowing to add fields in ways that
>> might later break.
>>
>> I'd be curious about other opinions though. (+Edwin, Daniel)
>>
>

On 11 September 2013 23:50, Tobias Grosser <tobias at grosser.es> wrote:
> 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
> on additional keywords, the harder it will be to add backward compatible
> extensions later on.
>
>
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.

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.



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.

The build tool that encodes much wisdom in this regard is in a prime
position to generate this extra information.

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.


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.

Cheers,

-nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130912/4ff87e76/attachment.html>