…e produced by keyword macro replacement

When later initial keyword macro replacement will yield a line that is
not Fortran source, don't interpret "&" as a Fortran source line
continuation marker during tokenization of the line.

Fixes https://github.com/llvm/llvm-project/issues/82579.

Change: remove guards on debug-printing, to allow Release builds without
LLVM_ENABLE_DUMP to pass.

MPInt is an arbitrary-precision integer library that builds on top of
APInt, and has a fast-path when the number fits within 64 bits. It was
originally written for the Presburger library in MLIR, but seems useful
to the LLVM project in general, independently of the Presburger library
or MLIR. Hence, move it into LLVM/ADT under the name DynamicAPInt.

This patch is part of a project to move the Presburger library into
LLVM.

The feature has been implemented in LLVM 18 as an experimental feature.
This marks the paper as complete and sets the feature-test macro.

Implements
- P2465R3 Standard Library Modules std and std.compat

Fixes: https://github.com/llvm/llvm-project/issues/89579

The paper
  P0768R1 Library Support for the Spaceship (Comparison) Operator
did not add a feature-test macro. This omission has been corrected in
  P1353R0 Missing Feature Test Macros

This enables the FTM for P0768R1

Fixes: https://github.com/llvm/llvm-project/issues/73953



---------

Co-authored-by: S. B. Tam <cpplearner@outlook.com>

In #94685 I discussed my ideas for cleaner baremetal output writing.
This patch is not that. This patch just uses `write_to_stderr` for
outputting from putchar and printf on baremetal. I'm still planning to
create a proper design for writing to stdout and stderr on various
platforms, but that will be a followup patch.

This is a fixup to https://github.com/llvm/llvm-project/pull/93808,
which used LDFLAGS instead of the correct LD_EXTRAS

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.