[clang] [Bounds Safety][NFC] Add `SemaBoundsSafety` class and move existing Sema checks there (PR #98954)
Aaron Ballman via cfe-commits
cfe-commits at lists.llvm.org
Wed Jul 17 05:46:41 PDT 2024
AaronBallman wrote:
> > > As noted above `-fbounds-safety` **is a C language extension** which makes it seem like it would fit nicely into the existing division of Sema into multiple objects and relevant source files.
> >
> >
> > No, it doesn't fit nicely into the division, which is the reason we're having this discussion.
>
> If we don't agree on this then I must not fully understand what the criteria is for dividing Sema current is.
The goal is to provide some layering within Sema to help break it up more. e.g., the base layer is C and C++ needs, but then there's a layer for Objective-C needs, a different layer for OpenMP needs, etc. This helps make it more clear where dependencies lie between the large-scale different semantic components. Bounds safety isn't really a "layer". Does that make some sense?
> > You can have `SemaBoundsSafety.cpp` and your own "section" inside `Sema.h`, like C++ features do (like templates or lambdas). There's no reason to make separation physical by introducing `SemaBoundsSafety` class from the get-go.
>
> I'm ok with this. Having the implementation in a separate file is where the main benefit lies. The separation into a separation into a separate class is a nice-to-have and ok to drop doing that.
>
> > That's why I propose to follow long-established practice of doing `SemaBoundsSafety.cpp`, and move that around later. What I'd like to evaluate before deciding on `SemaBoundsChecking` is how big its interface is (what would be exposed via `SemaBoundsChecking` class,)
>
> Sure. Let's go with that approach then.
Excellent, thank you!
https://github.com/llvm/llvm-project/pull/98954
More information about the cfe-commits
mailing list