(Sorry for the late response @alexr, the reply didn’t hit our inbox after email->discourse migration)
This started landing and I don’t see a clear acceptance of the premise here
Yes. Some RFCs seem to attract discussion of the details but the process doesn’t really drive towards an accept/deny conclusion. We understood this to mean it wasn’t terribly controversial as a peripheral part of the clang tooling libraries (not clang itself). Maybe this was wrong?
In fact, this project runs counter to several key design principles of clang
This sounds interesting/important, can you elaborate? I don’t think these were raised during the RFC.
If this were a new LLVM target, there would be much more discussion and yet this project appears to be of similar scale
Compared to a new target, it has much less impact on existing code/tools - there are no plans for this to be part of clang (the binary) or existing pieces of LLVM to depend on it.
Do you think it would be better if this kind of effort lived in clang-tools-extra/? The reason it’s under clang/ is to align with the existing Tooling/ libraries and because clang-tools-extra generally doesn’t contain libraries today.
It’s not completed, yet is being committed piecemeal
AIUI this is the preferred approach.
The patch reviews aren’t broadly covering key clang contributors.
This is is a good point. We’ve gotten high level design feedback from Richard Smith, @chandlerc, Yitzhak Mandelbaum but I don’t think they have interest/bandwidth in reviewing the implementation. Are there people interested doing this?