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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
