[cfe-dev] Criteria for Accepting Language Extensions into Clang

[Konstantin Tokarev]

21.07.2011, 21:40, "Douglas Gregor" <dgregor at apple.com>:
> For the last several years of Clang's development, our community has focused primarily on implementing existing language standards (C, C++, Objective-C) and improving compatibility with existing compilers (GCC, Visual C++). More recently, we've moved on to emerging standards (C++0x, C1x) and even started introducing significant language extensions not available in other compilers (e.g., Objective-C Automatic Reference Counting).
>
> Clang has always been designed as a platform for experimentation, and my hope is that Clang will be the premier vehicle for innovation in the C family of languages, establishing existing practice for the various standards committees. Sooner or later, the successful experiments will become proposed extensions for Clang, at which point we either fully commit to the extension--adding it into the tree and supporting it for many years ahead--or we must decide that the extension is not suitable for inclusion in Clang at this time. To aid in that decision, I propose the following seven criteria:
>
> 1) Evidence of a significant user community: This is based on a number of factors, including an actual, existing user community, the perceived likelihood that users would adopt such a feature if it were available, and any "trickle-down" effects that come from, e.g., a library adopting the feature and providing benefits to its users.
>
> 2) A specific need to reside within the Clang tree: There are some extensions that would be better expressed as a separate tool, and should remain as separate tools even if they end up being hosted as part of the LLVM umbrella project.
>
> 3) A complete specification: The specification must be sufficient to understand the design of the feature as well as interpret the meaning of specific examples. The specification should be detailed enough that another compiler vendor could conceivably implement the feature.
>
> 4) Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it.
>
> 5) A long-term support plan: Contributing a non-trivial extension to Clang implies a commitment to supporting that extension, improving the implementation and specification as Clang evolves. The capacity of the contributor to make that commitment is as important as the commitment itself.
>
> 6) A high-quality implementation: Naturally, the implementation must fit well into Clang's architecture, follow LLVM's coding conventions, and meet Clang's quality standards, including high-quality diagnostics and rich AST representations. This is particularly important for language extensions, because users will learn how those extensions work through the behavior of the compiler.
>
> 7) A proper test suite: Extensive testing is crucial to ensure that the language extension is not broken by ongoing maintenance in Clang. The test suite should be complete enough that another compiler vendor could conceivably validate their implementation of the feature against it.
>
> We intentionally set the bar high for language extensions because we *have* to set the bar high. A half-baked language extension is a cancer on the code base, and having many such extensions would threaten Clang's long-term growth. These criteria are intended to help potential contributors better prepare their extensions for inclusion in Clang, while helping the Clang project grow in a sustainable manner.


Thanks for clarification.

However, it would be great if it was easier to develop front-ends with language extensions without patching Clang code.

-- 
Regards,
Konstantin