The experimental PSTL's current dispatching mechanism was designed with
flexibility in mind. However, while reviewing the in-progress OpenMP
backend, I realized that the dispatching mechanism based on ADL and
default definitions in the frontend had several downsides. To name a
few:

1. The dispatching of an algorithm to the back-end and its default
   implementation is bundled together via `_LIBCPP_PSTL_CUSTOMIZATION_POINT`.
   This makes the dispatching really confusing and leads to annoyances
   such as variable shadowing and weird lambda captures in the front-end.
2. The distinction between back-end functions and front-end algorithms
   is not as clear as it could be, which led us to call one where we meant
   the other in a few cases. This is bad due to the exception requirements
   of the PSTL: calling a front-end algorithm inside the implementation of
   a back-end is incorrect for exception-safety.
3. There are two levels of back-end dispatching in the PSTL, which treat
   CPU backends as a special case. This was confusing and not as flexible
   as we'd like. For example, there was no straightforward way to dispatch
   all uses of `unseq` to a specific back-end from the OpenMP backend,
   or for CPU backends to fall back on each other.

This patch rewrites the backend dispatching mechanism to solve these
problems, but doesn't touch any of the actual implementation of
algorithms. Specifically, this rewrite has the following
characteristics:

- There is a single level of backend dispatching, however partial backends can
  be stacked to provide a full implementation of the PSTL. The two-level dispatching
  that was used for CPU-based backends is handled by providing CPU-based basis 
  operations as simple helpers that can easily be reused when defining any PSTL 
  backend.

- The default definitions for algorithms are separated from their dispatching logic.

- The front-end is thus simplified a whole lot and made very consistent
  for all algorithms, which makes it easier to audit the front-end for
  things like exception-correctness, appropriate forwarding, etc.

Fixes #70718

3 error_code related cleanups/corrections in the std::filesystem
operations functions.

1. In `__copy`, the `ec->clear()` is unnecessary as `ErrorHandler` at
the start of each function clears the error_code as part of its
initialization.

2. In `__copy`, in the recursive codepath we are not checking the
error_code result of `it.increment(m_ec2)` immediately after use in the
for loop condition (and we aren't checking it after the final increment
when we don't enter the loop).

3. In `__weakly_canonical`, it makes calls to `__canonical` (which
internally uses OS APIs implementing POSIX `realpath`) and we are not
checking the error code result from the `__canonical` call. Both
`weakly_canonical` and `canonical` are supposed to set the error_code
when underlying OS APIs result in an error
(https://eel.is/c++draft/fs.err.report#3.1). With this change we
propagate up the error_code from `__canonical` caused by any underlying
OS API failure up to the `__weakly_canonical`. Essentially, if
`__canonical` thinks an error code should be set, then
`__weakly_canonical` must as well. Before this change it would be
throwing an exception in the non-error_code form of the function when
`__canonical` fails, while not setting the error code in the error_code
form of the function (an inconsistency).

Added a little coverage in weakly_canonical.pass.cpp for the error_code
forms of the API that was missing. Though I am lacking utilities in
libcxx testing to add granular testing of the failure scenarios (like
forcing realpath to fail for a given path, as it could if you had
something like a flaky remote filesystem).

Pick the latest version available in Chocolatey (18.1.6) and llvm-mingw
(20240606, which includes LLVM 18.1.7).

Also add the flag "--allow-downgrade" when installing a specific version
of LLVM. If the preinstalled version is higher than the requested one,
Chocolatey would otherwise error out when requesting installing a lower
version. This will avoid errors in the future, if the runner image comes
preinstalled with a newer version of LLVM.

(This currently seems to happen with a recent version of the GitHub
Actions runner image, version 20240610.1.0 has LLVM 18.1.6 already
preinstalled, and will error out when trying to install the 17.0.6
version that we previously requested.)

These tests do not require bash. Skip them because they use features not
available on Windows. This is a follow up to #94595.

Prior to 84780af4, the class didn't have
any information about whether the saved value was volatile.

This is NFC as far as I can tell.

Nothing uses wget - only curl is used, and that's available out of the
box.

Restrict `DropInnerMostUnitDimsTransferRead` so that it fails when one
of the indices to be dropped could be != 0, e.g.

```mlir
func.func @negative_example(%A: memref<16x1xf32>, %i:index, %j:index) -> (vector<8x1xf32>) {
  %f0 = arith.constant 0.0 : f32
  %1 = vector.transfer_read %A[%i, %j], %f0 : memref<16x1xf32>, vector<8x1xf32>
  return %1 : vector<8x1xf32>
}
```

This is an edge case that could represent an out-of-bounds access,
though that will depend on the actual value of `%j`. Importantly,
_without this change_ it would be transformed as follows:
```mlir
  func.func @negative_example(%arg0: memref<16x1xf32>, %arg1: index, %arg2: index) -> vector<8x1xf32> {
    %cst = arith.constant 0.000000e+00 : f32
    %subview = memref.subview %arg0[0, 0] [16, 1] [1, 1] : memref<16x1xf32> to memref<16xf32, strided<[1]>>
    %0 = vector.transfer_read %subview[%arg1], %cst : memref<16xf32, strided<[1]>>, vector<8xf32>
    %1 = vector.shape_cast %0 : vector<8xf32> to vector<8x1xf32>
    return %1 : vector<8x1xf32>
  }
```

This is incorrect - `%arg2` is ignored. Hence the extra restriction to
avoid such cases.

NOTE: This PR is limited to tests for `vector.transfer_read`.

When PIE is enabled on a platform by default, these tests fail since the
`target variable` command can't read a global string variable value
before running an inferior process.

It fixes the following tests when built with clang on Ubuntu aarch64:
```
commands/target/basic/TestTargetCommand.py
lang/c/global_variables/TestGlobalVariables.py
lang/cpp/char8_t/TestCxxChar8_t.py
```

My reverted attempt to decouple feature dependency expansion (see
#95056) made it evident that some features are still using the FMV
dependencies in the target attribute.

The original commit broke the llvm test suite. This was addressed here:
https://github.com/llvm/llvm-test-suite/pull/133. I am now relanding it.

Use more flexable regex ([0-9]+) for frame number checks. Since the
frame numbers might change if some functions are not inlined.

Similar to
*
https://github.com/llvm/llvm-project/commit/0360f3218a13666123849f6699216bdbebe64833
*
https://github.com/llvm/llvm-project/commit/404bc5ca2ae5fffa45d5240dcf52b7f134988867

Swap out range metadata to range attribute for calls to be able to
deprecate range metadata on calls in the future.

This patch adds adds patterns to fold memref alias for
expand_shape/collapse_shape feeding into vector.load/vector.store and
vector.maskedload/vector.maskedstore

This fixes https://github.com/llvm/llvm-project/issues/93886. The UnitID
is not
unique between CUs and TUs. This led to DW_IDX_parent to point ot an
entry for a
DIE in a CU if it had the same relative offset as a TU die.

Added a IsTU to the hash for parent chain.

COV3 is not supported anymore, thus we can just use ArgsSize we read
from the kernel to determine how many argument bytes we need and if
implicit kernel arguments are used.

As Step is VF * UF, there is no need to compute it again, which may
require multiple instructions for scalable VFs.

There is currently support for lowering directives that appear outside
of a module or procedure, or inside the body of a module or procedure.
Extend this to support directives at the CONTAINS level of a module or
procedure, such as directives 3, 5, 7 9, and 10 in:

    !dir$ some directive 1
    module m
      !dir$ some directive 2
    contains
      !dir$ some directive 3
      subroutine p
        !dir$ some directive 4
      contains
        !dir$ some directive 5
        subroutine s1
          !dir$ some directive 6
        end subroutine s1
        !dir$ some directive 7
        subroutine s2
          !dir$ some directive 8
        end subroutine s2
        !dir$ some directive 9
      end subroutine p
      !dir$ some directive 10
    end module m
    !dir$ some directive 11

This is done by looking for CONTAINS statements at the module or
procedure level, while ignoring CONTAINS statements at the derived type
level.

This PR carves out small portion of the test in subject to avoid the
following failure when unicode is not available.

```
# | Assertion failure: result == expected .../formatter.char.funsigned-char.pass.cpp 56
# |
# | Format string   ?}
# | Expected output '\x{80}'
# | Actual output   '�'
```

This was traced down to different definition of
`__code_point_view::__consume()` under macro_LIBCXX_HAS_NO_UNICODE which
is called inside `__formatter::__escape()`. The `__consume()` returns
`__ok` and code assumes that escaped sequence was already written but it
is not., thus the failure. Here is the snippen code we fall into:

```
    typename __unicode::__consume_result __result = __view.__consume();
    if (__result.__status == __unicode::__consume_result::__ok) {
      __escape = __formatter::__is_escaped_sequence_written(__str, __result.__code_point, __escape, __mark);
```

This reverts commit ad9fe3b2.

Text files should be opened with OF_Text to have the correct encoding.

Always match AVG patterns pre-legalization, and use TargetLowering::expandAVG to expand again during legalization.

I've removed the X86 custom AVGCEILU pattern detection and replaced with combines to try and convert other AVG nodes to AVGCEILU.

Also use opaque pointers.

It's very expensive and doesn't achieve anything.

I one test I did, it saves almost 10s on a 2m23s build, bringing it down
to 2m15s using a downstream branch.

The checker `alpha.core.SizeofPtr` was a very simple checker that did
not rely on path sensitive analysis and was very similar to the (more
complex and refined) clang-tidy check `bugprone-sizeof-expression`.

As there is no reason to maintain two separate implementations for the
same goal (and clang-tidy is more lightweight and accessible than the
Analyzer) I decided to move this functionality from the Static Analyzer
to clang-tidy.

Recently my commit 546c816a
reimplemented the advantageous parts of `alpha.core.SizeofPtr` within
clang-tidy; now this commit finishes the transfer by deleting
`alpha.core.SizeofPtr`.

Currently, OpenMP operations are defined independently of each other.
However, one property of the OpenMP specification is that many clauses
can be applied to multiple constructs.

Keeping the MLIR representation of clauses consistent across all
operations that can accept them is important, but since this information
is scattered into multiple operation definitions, it is currently prone
to divergence as new features and changes are added to the dialect.
Furthermore, centralizing this information allows for a single source of
truth and avoids redundancy in the dialect.

The proposal in this patch is to make OpenMP clauses independent top
level definitions which can then be passed in a template argument list
to OpenMP operation definitions, just as it's done for traits. Clauses
can define these properties, which are joined together in order to make
a default initialization for the fields of the same name of the OpenMP
operation:

- `traits`: Optional. It gets added to the list of traits of the
operation.
- `arguments`: Mandatory. It defines how the clause is represented.
- `assemblyFormat`: Optional (though it should almost always be
defined). This is the declarative definition of the printer/parser for
the `arguments`. How these are combined depends on whether this is an
optional or required clause.
- `description`: Optional. It's used to populate a `clausesDescription`
field, so each operation definition must still define a `description`
itself. That field is intended to be appended to the end of the
`OpenMP_Op`'s `description`.
- `extraClassDeclaration`: Optional. It can define some C++ code to be
added to every OpenMP operation that includes that clause.

In order to give operation definitions fine-grained control over
features of a certain clause might need to be inhibited, the
`OpenMP_Clause` class takes "skipTraits", "skipArguments",
"skipAssemblyFormat", "skipDescription" and "skipExtraClassDeclaration"
bit template arguments. These are intended to be used very sparingly for
cases where some of the clauses might collide in some way otherwise.

This adds the documentation for a few recently added Clang API Notes
features: C++ namespaces, `SwiftImportAs` and `SwiftCopyable`.

---------

Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>

improve `ASTStructuralEquivalenceTest`:

1. compare the depth and index of NTTP
2. provide comparison of `CXXDependentScopeMemberExpr` to `StmtCompare`.

Co-authored-by: huqizhi <836744285@qq.com>

otherwise it's not guaranteed which of two candidates with the same
score would get specialized first, or at all.

close: #86301

This patch adds support for lowering the OpenMP DISTRIBUTE directive
from PFT to MLIR. It only supports standalone DISTRIBUTE, support for
composite constructs will come in follow-up PRs.