Clang documents our criteria for adding a new extension to the compiler, but one thing our policy lacks is attention to how Clang interacts with the rest of the LLVM Project ecosystem: there are no criteria for impacts to libc++, lldb, compiler-rt, etc. As a result, when the community evaluates a proposed new extension, we often do it from a somewhat isolated perspective which can result in a poor user experience.
As a concrete example of what I mean, the __restrict qualifier extension in C++ is treated as a cv-qualifier in Clang, including allowing it to be written on a member function. This impacts libc++ because e.g. std::function and std::invoke need to be able to invoke qualified member functions, and qualifiers have a combinatorial number of cases to consider for both tests and within the implementation.
To address this concern, I am proposing the following addition to our existing criteria:
A support story for other impacted projects within the monorepo: If the extension can impact other parts of the project (libc++, lldb, compiler-rt, etc), the proposal needs to document the impact for these projects to fully support the extension and what what level of support is expected. The impacted project communities need to agree with that plan.
The intent of this addition is to ensure the community is making a more informed decision about a proposal by getting feedback from more stakeholders, and to identify unintentional impacts, missing functionality, necessary additional documentation, or design changes. With the extra context, the community may decide that support outside of Clang is a crucial need for consensus on the proposal, or may decide that the extra support is a nice-to-have rather than a requirement, etc.
I think that considering the overall ecosystem/toolchain is important to provide extensions that work well for our users. Otherwise, folks start using these extensions thinking they will work like they’d expect, only to realize that none of the tools they use really handle them. We can then get in the situation that an extension is being used a lot in the wild despite it having obvious shortcomings in e.g. the library, without always a way to address those shortcomings.
LLVM, as the entire project, should make sure we have a coherent story and ecosystem. Divergence is not always avoidable but we should be careful.
At least from my personal point of view, I think vanilla LLVM should provide the user with the tools and capabilities first, and empower downstream enhancements second.
At least from my personal point of view, I think vanilla LLVM should provide the user with the tools and capabilities first, and empower downstream enhancements second.
I’m puzzled by what this means, particularly in the context of Aarons posting. What’s the connection between a Clang extension and a “downstream enhancement”?
It was a generic comment that might not fit this particular example. Basically, what I want to say is that we should first and foremost focus on delivering capabilities without outside dependences, where possible. As an example of something I don’t like (for various reasons), look at the pstl folder in which we have a parallel libc++ but it requires TBB. I’m not trying to say TBB is bad, but we have a parallel runtime in LLVM and we should have set it up on that one first. Similarly, I’m trying to force the new offloading languages, e.g., OpenACC, to target LLVM/Offload such that upstream is a working offload-capable compiler without the specific vendor library of the vendor that happens to implement this language frontend. Does that make more sense?
Thank you to everyone who has left feedback! Discussion seems to be winding down and it doesn’t sound like there’s any contention with the RFC, so I think this RFC is accepted. I’ll put together a patch to change the webpage sometime early next week, in case there’s last-minute feedback.
Clang: consensus called in this message.