AaronBallman wrote: > What is the goal here?
The eventual goal is for Sema to have appropriate layering instead of being a monolithic design. "Appropriate layering" can be handled in many different ways, but the goal when this was discussed extensively in the past was to split by "category" where some categories are language-based (splitting OpenACC from HLSL from Objective-C, etc) and some categories are feature-based (splitting attributes from coroutines from constant expression evaluation). Clang is designed to be a library and our semantic layer is... not. So the goal is to eventually partition these into separable concerns so it is easier to maintain and so some parts can be reused (for example, constant expression evaluation could be helpful for clang-tidy while still not needing to expose the entirety of Sema to achieve it). This is obviously a very long-term goal, and also a bit of a research effort in terms of where to draw the line for such a monolithic part of the compiler. > We had buy-in to split languages out and I think that has been successful > (with painful churns). FWIW, I have not received any reports about churn being painful from downstreams. This was discussed at a previous Clang Language WG meeting and the only pain this has caused that I'm aware of has been the usual "it's hard to track against ToT" variety that we get with any significant maintenance of the project. If there are worse problems than that, it would be good to get details about them. We need the ability to maintain and evolve Clang, so fear of churn without evidence of harm is not a blocking concern. That said, if there's some concrete reason the churn outweighs the benefits of the split, that is a different situation. > Splitting out individual C++ features or even C from C++ is a different > proposition all together because these things are naturally interweaved, and > we quickly get diminishing returns (and increased churns), at the cost of > more clumsy APIs (ie things like SemaAccess() everywhere and thing harder to find or organized) I think this is part of the investigative work and I disagree with a blanket prohibition against splitting out features, at least at this early of a stage. IMO, we should evaluate the benefits for each component on their own merits and push back splitting up where it doesn't make sense to do so. Specific to splitting out coroutines, I can see arguments in either direction. It's pretty trivial to split out because it's built "on top" of Sema rather than deeply integrated with it like C and C++ support are. However, it's not clear that it can ever be a reusable component and it's also not clear whether we want to go as far as what [Chuanqi's comment](https://github.com/llvm/llvm-project/pull/92645#issuecomment-2119530823) suggests in terms of layering. Given the concerns raised here, it might make sense to put this change on hold, do a few more similar experiments for other parts of C++, and see what sort of principled design approach makes sense to take here. My current thinking (which could be off-base!) is that for language features strongly tied to language semantics (like coroutines), if we do split them then it probably makes sense to split those off in a language-based approach (`getSema().CXX().Coroutines().whatever`) whereas more language-agnostic concepts (like constant expression evaluation) might make sense to split off into their own component whose language-specific behavior can be controlled by a traits object of some kind (`getSema().ConstExpr<SemaCXX>().whatever`). https://github.com/llvm/llvm-project/pull/92645 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
