[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:

The "record have key_type, value_type, and .at method" suggestion would blindly exclude any map-related at() method, even if its semantics are different, correct? 
Do you think this could cause any issues? Is it fair to assume that other libraries will define it so that it needs to be excluded?
Worst case, we have false negatives. Or am I misunderstanding something?

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