Endilll wrote: > > If you take a close look at the existing set of `Sema` parts, it's almost > > entirely comprised of other languages or language extensions (from C and > > C++ standpoint) and backends. They were considered natural enough to be > > split off `Sema`, which, among other things, means that it's easy to > > explain their place in the big picture, like I did in the previous sentence. > > I don't have a strong opinion on whether this should be split up, but I just > wanted to point out that `-fbounds-safety` is also a language extension, so > it does kind of fit your description of other things separated out.
"Extension" is definitely quite broad. What I meant are (basically) languages that are based off C or C++. Would you argue that `-fbounds-safety` fits into a set of OpenMP, OpenACC, CUDA, HLSL, Objective-C, and Swift? > It's currently in the process of being upstreamed which is why it's small, > but it'd be easier to split now than wait until it's reached a certain size, > if we do want to split it eventually. I did that a lot with other parts of `Sema`, and it's not that hard, unless it grows comparable to `SemaExprCXX.cpp` (which I consider unlikely to happen). I'd rather see this being upstreamed into the existing `Sema` structure as it has been planned all along, and use it as an input for the design of further `Sema` splitting, rather than committing today that `SemaBoundsSafety` is going to be a thing. https://github.com/llvm/llvm-project/pull/98954 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
