[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,50 @@
+.. title:: clang-tidy - cppcoreguidelines-pro-bounds-avoid-unchecked-container-accesses
+
+cppcoreguidelines-pro-bounds-avoid-unchecked-container-accesses
+===============================================================
+
+Flags calls to ``operator[]`` in STL containers and suggests replacing it with
+safe alternatives.
+
+For example, both
+
+.. code-block:: c++
+
+  std::vector<int> a;
+  int b = a[4];
+
+and
+
+.. code-block:: c++
+
+  std::unique_ptr<vector> a;
+  int b = a[0];
+
+will generate a warning.
+
+STL containers with well-defined behavior for ``operator[]`` are excluded from this
+check.
+
+This check enforces part of the `SL.con.3
+<https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#slcon3-avoid-bounds-errors>`
+guideline and is part of the `Bounds Safety (Bounds 4)
+<https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Pro-bounds-arrayindex>`
+profile from the C++ Core Guidelines.
+
+Options
+-------
+
+.. option:: ExcludeClasses
+
+    Semicolon-delimited list of class names that should additionally be
----------------
paulhdk wrote:

Re: 2, how would you differentiate the two cases where a user doesn't specify anything, i.e., wants the default exclusions, vs a user explicitly wanting to disable the default exclusions? In both cases, the check would receive an empty string as an argument, wouldn't it?

I'm also unsure if it makes sense to allow users to disable the default behaviour in the first place as it will defeat the purpose of the pass.

How about I just make the default exclusions explicit in the documentation. Something along the lines of: 
> STL containers with well-defined behavior for operator[], i.e., std::map, std::unordered_map, and std::flat_map, are excluded from this
check.

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