[cfe-dev] JSONCompilationDB Parser
Arnaud A. de Grandmaison
arnaud.allarddegrandmaison at parrot.com
Fri Nov 30 00:32:11 PST 2012
On 11/29/2012 09:11 PM, Tobias Grosser wrote:
> 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.
I also like the idea of a reserved namespace for 3rd party extensions.
>> (& 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)?
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
Arnaud de Grandmaison
More information about the cfe-dev