delcypher 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. > 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. 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
