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

[Paul Heidekrüger via cfe-commits]

================
@@ -0,0 +1,124 @@
+//===--- ProBoundsAvoidUncheckedContainerAccesses.cpp - clang-tidy --------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "ProBoundsAvoidUncheckedContainerAccesses.h"
+#include "../utils/Matchers.h"
+#include "../utils/OptionsUtils.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "llvm/ADT/StringRef.h"
+#include <numeric>
+
+using namespace clang::ast_matchers;
+
+namespace clang::tidy::cppcoreguidelines {
+
+static constexpr std::array<llvm::StringRef, 3> SubscriptDefaultExclusions = {
+    llvm::StringRef("::std::map"), llvm::StringRef("::std::unordered_map"),
+    llvm::StringRef("::std::flat_map")};
----------------
PBHDK wrote:

> Should be fine, other option would be to check if at and [] parameters as integers, and do not come from template.

In this case, we would just iterate over all arguments of `operator[]` and `at()` call - in C++ 23, there could be multiple - and check if they're integers and don't come from a template. This would eliminate the need for hard-coded types, correct? However, we would still keep the exclusion list mechanism so that users can exclude their custom range-checked subscript operator overloads. Do you think this can be easily implemented like this?

> Or other option even better instead of having exclusions list, have inclusion list. and just configure check for std::array, std::vector, std::span, gsl::span, std::deque. That would be better, than trying to exclude some not related types.

There'd still be hard-coded types in this case, but we drastically reduce the risk of false positives, correct? However, we would still be missing a lot of cases in custom libraries or user-defined overloads of the subscript operator, which were explicitly requested in other discussions, IIRC. Would you still prefer this over the first suggestion, even though we would be missing cases?

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