delcypher wrote:
> "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? In my opinion it fits in the set because it is a (pretty large) C language extension. > > 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. I don't agree with this approach. I outlined above why I think it makes a lot of sense to keep the `-fbounds-safety` Sema code in its own source file and blocking doing that on a _potential future refactor_ that might never happen doesn't seem like a good idea to me. If at some point we come up with some new design for Sema we can easily move the `-fbounds-safety` code out of its own source file (and class) and into the relevant locations required by the redesign. If the `-fbounds-safety` code is littered all over the other Sema files the "potential future refactor" could be much harder because finding all `-fbound-safety` code now is much more time consuming. 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
