[cfe-dev] JSONCompilationDB Parser

[Tobias Grosser]

On 11/29/2012 08:42 PM, David Blaikie wrote:
> If we really want to do this to deliberately allow 3rd party fields in
> the database it's probably worthwhile having some kind of defined
> namespace (either for our names or for the 3rd party names) so that
> future extensions to our schema don't conflict with 3rd party fields.

Having namespaces for third-party plugins is a good idea.

> (& in that case we could still hard-error (if we want to) on fields in
> our namespace that are unknown (Tobias's position to be considered -
> only works if new fields are always acceptable to be ignored))

Regarding our (or the global) namespace, it would be interesting to know 
if we expect additions that are not acceptable to be ignored. I assumed 
additional fields provide additional information that would just be 
missing if the fields are not read. Similar to libclang.so we could 
provide additional information in new fields, but we could agree to not 
change the semantics of existing fields.

I am mainly concerned about backwards compatibility issues. It may be 
helpful to clarify if we want to remain compatible with older versions 
of clang and in case we do, how we want to ensure compatibility. Is my 
understanding correct that the current code will make clang versions 
error out, in case they read a compilation database that includes 
extensions we may possibly add ourselves at some point in the future? In 
case this is true, how would we handle such a situation? Are there other 
solutions than requiring the user to upgrade to the most recent version 
of clang (possibly not yet in his package repository or not installed by 
his sysadmins)?

Cheers
Tobi