[clang] [Bounds Safety][NFC] Add `SemaBoundsSafety` class and move existing Sema checks there (PR #98954)
Vlad Serebrennikov via cfe-commits
cfe-commits at lists.llvm.org
Mon Jul 15 14:59:04 PDT 2024
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
More information about the cfe-commits
mailing list