Merge branch 'main' of https://github.com/llvm/llvm-project into users/ccc/create-AvoidnestedternaryconditionaloperatorCheck

Haiku and Solaris need some additional libraries after the commit
c0d5d36d

Otherwise fails to link a whole bunch of the tools and other binaries
with undefined symbols with accept() and connect().

I did a static and dynamic build on illumos and a dynamic build on
Haiku.

```
-DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld;mlir'
```
and on illumos
```
-DLLVM_ENABLE_RUNTIMES='openmp'
```

[clang-tidy]fix readability-implicit-bool-conversion false-positives when comparison bool bitfield (#77878)

Fixes: #76817
For ignoring comparison and xor operator, it needs
to use `ImplicitCastFromBool` without ignoring
exception cases.
This patch splits ignoring exception cases logic
from `ImplicitCastFromBool` and only applies
it during matching targeted AST.

...and tests.

---------

Co-authored-by: Zingam <zingam@outlook.com>

Resolves #78014

Added support for size-like method returning signed type, and corrected
false positive caused by always-false check for size bellow zero.

Closes #72619

Support detecting redundant in-class initializers. 
Moved from https://reviews.llvm.org/D157262

Fixes: #62525

llvm-project/llvm/include/llvm/Analysis/DOTGraphTraitsPass.h:89:13:
 error: 'static' function 'shortenFileName' declared in header file should be declared 'static inline' [-Werror,-Wunneeded-internal-declaration]
  static void shortenFileName(std::string &FN, unsigned char len = 250) {

`buildUnrealizedCast` used to generate invalid
`builtin.unrealized_conversion_cast` ops with zero results. This commit
fixes
`test/Conversion/OneToNTypeConversion/one-to-n-type-conversion.mlir`
when running with `MLIR_ENABLE_EXPENSIVE_PATTERN_API_CHECKS`.

```
  * Pattern (anonymous namespace)::ConvertMakeTupleOp : 'test.make_tuple -> ()' {
Trying to match "(anonymous namespace)::ConvertMakeTupleOp"

[...]

"(anonymous namespace)::ConvertMakeTupleOp" result 1
  } -> success : pattern applied successfully
// *** IR Dump After Pattern Application ***
mlir-asm-printer: Verifying operation: func.func
'builtin.unrealized_conversion_cast' op expected at least one result for cast operation
mlir-asm-printer: 'func.func' failed to verify and will be printed in generic form
"func.func"() <{function_type = (i1, i2) -> (i1, i2), sym_name = "pack_unpack"}> ({
^bb0(%arg0: i1, %arg1: i2):
  %0 = "test.make_tuple"() : () -> tuple<>
  "builtin.unrealized_conversion_cast"(%0) {"__one-to-n-type-conversion_cast-kind__" = "target"} : (tuple<>) -> ()

[...]

}) : () -> ()

within split at /usr/local/google/home/springerm/mlir_public/llvm-project/mlir/test/Conversion/OneToNTypeConversion/one-to-n-type-conversion.mlir:1 offset :20:8: error: 'builtin.unrealized_conversion_cast' op expected at least one result for cast operation
  %0 = "test.make_tuple"() : () -> tuple<>
       ^
within split at /usr/local/google/home/springerm/mlir_public/llvm-project/mlir/test/Conversion/OneToNTypeConversion/one-to-n-type-conversion.mlir:1 offset :20:8: note: see current operation: "builtin.unrealized_conversion_cast"(%0) {"__one-to-n-type-conversion_cast-kind__" = "target"} : (tuple<>) -> ()
LLVM ERROR: IR failed to verify after pattern application
```

llvm-project/clang/tools/libclang/linker-script-to-export-list.py:9: SyntaxWarning: invalid escape sequence '\s'
  m = re.search("^\s+(clang_[^;]+)", line)

Co-authored-by: cor3ntin <corentinjabot@gmail.com>

Reorder checks & fix some formating.

Added support for iter_swap, iter_move in bugprone-exception-escape 
and performance-noexcept-swap checks.

Fixes  #75686

See:
https://github.com/llvm/llvm-project/pull/76086#issuecomment-1890424955

Fix #60081.

Refactoring started in https://github.com/llvm/llvm-project/pull/73879 has unfortunately missed to add indentation to `expected-note` directives. This patch is a follow-up to that refactoring.

We previously scanned the whole BB for `DBG_VALUE` instruction even when
the program doesn't have debug info, i.e., the function doesn't have a
subprogram associated with it, which can make compilation unnecessarily
slow. This disables `DebugValueManager` when a `DISubprogram` doesn't
exist for a function.

This only reduces unnecessary work in non-debug mode and does not change
output, so it's hard to add a test to test this behavior.

Test changes were necessary because their `DISubprogram`s were not
correctly linked with the functions, so with this PR the compiler
incorrectly assumed the functions didn't have a subprogram and the tests
started to fail.

Fixes https://github.com/emscripten-core/emscripten/issues/21048.

[P1787](https://wg21.link/p1787): The intent for CWG2335 (contra those of the older CWG1890, CWG1626, CWG1255, and CWG287) is supported by retaining the unrestricted forward lookup in complete-class contexts (despite current implementation behavior for non-templates).

Wording: The declaration set is the result of a single search in the scope of C for N from immediately after the class-specifier of C if P is in a complete-class context of C or from P otherwise. [Drafting note: The plan for CWG2335 is to describe forbidden dependency cycles among the complete-class contexts of a class. — end drafting note] ([class.member.lookup]/4)

Complete-class context is described in [class.mem.general] [p7](http://eel.is/c++draft/class#mem.general-7) and
[p8](http://eel.is/c++draft/class#mem.general-8). In this patch I add tests only for CWG issues that fall under current definition of complete-class context, because I'm not sure how CWG1255 and CWG287 are going to work. That's why I skip over them, but mark CWG1308 as superseded by CWG1330.

Test is based on [P0136R1](https://wg21.link/p0136r1) wording instead of proposed resolution in the issue itself.

This patch also expands related CWG1573 test with an additional test case. Existing `3.9` status of 1573 is still relevant even with this new test case.

Reverts llvm/llvm-project#77832

To fix https://lab.llvm.org/buildbot/#/builders/236/builds/8673

Also truncation to shorter type looks incorrect.

Issue for tracking #78024 .

GCC 13 is the latest GCC release and tested in the libc++ CI for several
month. According to our policy we only support the latest version,
update the documentation to the latest version.

Co-authored-by: Zingam <zingam@outlook.com>

The check currently emits warnings for the following code:
    `uint64_t fn() { return 1024 * 1024; }`

But the code generated after applying the notes will look like this:
    `uint64_t fn() { return static_cast<uint64_t>(1024 * )1024; }`

This is because when generating the notes the check will use the
beginLoc() and EndLoc() of the subexpr of the implicit cast.
But in some cases the AST Node might not have a beginLoc and EndLoc.
This seems to be true when the Node is composed of only 1 token (for
example an integer literal). Calling the getEndLoc() on this type of
node will simply return the known location which is, in this case, the
beginLoc.

Fixes #63070 #56728

This commit turns on ASan annotations in `std::basic_string` for all
allocators by default.

Originally suggested here: https://reviews.llvm.org/D146214

String annotations added here:
https://github.com/llvm/llvm-project/pull/72677

This commit is part of our efforts to support container annotations with
(almost) every allocator. Annotating `std::basic_string` with default
allocator is implemented in
https://github.com/llvm/llvm-project/pull/72677.

Additionally it removes `__begin != nullptr` because `data()` should
never return a nullptr.

Support in ASan API exists since
https://github.com/llvm/llvm-project/commit/1c5ad6d2c01294a0decde43a88e9c27d7437d157.
This patch removes the check in std::basic_string annotation member
function (__annotate_contiguous_container) to support different
allocators.

You can turn off annotations for a specific allocator based on changes
from
https://github.com/llvm/llvm-project/commit/2fa1bec7a20bb23f2e6620085adb257dafaa3be0.

The motivation for a research and those changes was a bug, found by
Trail of Bits, in a real code where an out-of-bounds read could happen
as two strings were compared via a call to `std::equal` that took
`iter1_begin`, `iter1_end`, `iter2_begin` iterators (with a custom
comparison function). When object `iter1` was longer than `iter2`, read
out-of-bounds on `iter2` could happen. Container sanitization would
detect it.

If you have any questions, please email:
- advenam.tacet@trailofbits.com
- disconnect3d@trailofbits.com