[clang-tools-extra] Enforce SL.con.3: Add check to replace operator[] with at() [Cont.] (PR #95220)

[Carlos Galvez via cfe-commits]

Paul =?utf-8?q?Heidekrüger?= <paul.heidekrueger at tum.de>,
Paul =?utf-8?q?Heidekrüger?= <paul.heidekrueger at tum.de>,
Paul =?utf-8?q?Heidekrüger?= <paul.heidekrueger at tum.de>,
Paul =?utf-8?q?Heidekrüger?= <paul.heidekrueger at tum.de>,
Paul =?utf-8?q?Heidekrüger?= <paul.heidekrueger at tum.de>,
Paul =?utf-8?q?Heidekrüger?= <paul.heidekrueger at tum.de>,
Paul =?utf-8?q?Heidekrüger?= <paul.heidekrueger at tum.de>,
Paul =?utf-8?q?Heidekrüger?= <paul.heidekrueger at tum.de>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/95220 at github.com>


carlosgalvezp wrote:

> exception information is in LangOptions. It should be the same as c++ version.

I see, that's good. Worth mentioning is that just because "-fno-except" is not present, it does not mean that a project bans exceptions. For example libstdc++/libc++ is typically compiled with exceptions; this won't play well with client code compiled with -fno-except.

Even if exceptions were allowed, one can also argue if out-of-bounds is a place that grants usage of exceptions. In some views, exceptions are meant only for truly exceptional situations (e.g. out-of-memory), whereas out-of-bounds is generally seen as a programmer error (contract violation).

I don't want to dive deep into such discussion, my point is that error handling is a very debatable topic and also a core design choice to any C++ project, and as such I don't think clang-tidy shouldn't be taking a stance on it. Otherwise some people will be forced to disable a great check (detects violations) due to unwanted fix-it/suggestions (which junior devs may blindly follow without full context).

I think clang-tidy could offer an enum option for the fix, like:

```
FixMode: None        // no fix (default)
FixMode: at             // use <container>::at()
FixMode: function   // use a user-defined function, for example gsl::at(), as shown in the C++ Core Guidelines
```

https://github.com/llvm/llvm-project/pull/95220