Using CMake >=3.20 results in many warnings about this new policy. This change silences the warnings by explicitly declaring use of the "OLD" behavior.

This applies D101083 to LLDBStandalone.cmake.

Differential Revision: https://reviews.llvm.org/D112497

This is what ld64 does too, so we have parity here (though I think ld64
still removes dead code more effectively than we do...)

Reviewed By: #lld-macho, thakis

Differential Revision: https://reviews.llvm.org/D112485

Avoid naming some Expected<T> values in the Bitcode reader by using
takeError() and moveInto() more often. This follows the smaller set of
changes included in 2410fb46.

Motivation:

At the moment it is hard to attribute a clangd crash to a specific request out of all in-flight requests that might be processed concurrently. So before we can act on production clangd crashes, we have to do quite some digging through the log tables populated by our in-house VSCode extension or sometimes even directly reach out to the affected developer. Having all the details needed to reproduce a crash printed alongside its stack trace has a potential to save us quite some time, that could better be spent on fixing the actual problems.

Implementation approach:

* introduce `ThreadCrashReporter` class that allows to set a temporary signal handler for the current thread
* follow RAII pattern to simplify printing context for crashes occurring within a particular scope
* hold `std::function` as a handler to allow capturing context to print
* set local `ThreadCrashReporter` within `JSONTransport::loop()` to print request JSON for main thread crashes, and in `ASTWorker::run()` to print the file paths, arguments and contents for worker thread crashes

`ThreadCrashReporter` currently allows only one active handler per thread, but the approach can be extended to support stacked handlers printing context incrementally.

Example output for main thread crashes:

  ```
  ...
  #15 0x00007f7ddc819493 __libc_start_main (/lib64/libc.so.6+0x23493)
  #16 0x000000000249775e _start (/home/emmablink/local/llvm-project/build/bin/clangd+0x249775e)
  Signalled while processing message:
  {"jsonrpc": "2.0", "method": "textDocument/didOpen", "params": {"textDocument": {"uri": "file:///home/emmablink/test.cpp", "languageId": "cpp", "version": 1, "text": "template <typename>\nclass Bar {\n  Bar<int> *variables_to_modify;\n  foo() {\n    for (auto *c : *variables_to_modify)\n      delete c;\n  }\n};\n"}}}
  ```

Example output for AST worker crashes:

  ```
  ...
  #41 0x00007fb18304c14a start_thread pthread_create.c:0:0
  #42 0x00007fb181bfcdc3 clone (/lib64/libc.so.6+0xfcdc3)
  Signalled during AST action:
  Filename: test.cpp
  Directory: /home/emmablink
  Command Line: /usr/bin/clang -resource-dir=/data/users/emmablink/llvm-project/build/lib/clang/14.0.0 -- /home/emmablink/test.cpp
  Version: 1
  Contents:
  template <typename>
  class Bar {
    Bar<int> *variables_to_modify;
    foo() {
      for (auto *c : *variables_to_modify)
        delete c;
    }
  };
  ```

Testing:

The unit test covers the thread-localitity and nesting aspects of `ThreadCrashReporter`. There might be way to set up a lit-based integration test that would spawn clangd, send a message to it, signal it immediately and check the standard output, but this might be prone to raceconditions.

Reviewed By: sammccall

Differential Revision: https://reviews.llvm.org/D109506

Reviewed By: Mogball

Differential Revision: https://reviews.llvm.org/D112468

This change adds additional unit tests for availability attribute
support for Fuchsia platform.

Differential Revision: https://reviews.llvm.org/D112271

Removed references to `sanity check` in `PPCBranchCoalescing.cpp` code comments.
No word substitution made in this case, as the comments and code following illustrated are
sufficient IMO.

Reviewed By: quinnp

Differential Revision: https://reviews.llvm.org/D112452

Previously, strtol/ll/ul/ull would return a pointer to the end of its
parsing, regardless of if it detected a number. Now it will return a
length of 0 when it doesn't find a number.

Reviewed By: sivachandra

Differential Revision: https://reviews.llvm.org/D112176

offsets as two separate entities to the plugins.

In TSan, we use the a function reference (`__tsan_stack_initialization`)
in a call to `StackTrace::GetNextInstructionPc(uptr pc)`.  We sign
function pointers, so we need to strip the signature from this function
pointer.

Caused by: https://reviews.llvm.org/D111147

Radar-Id: rdar://problem/83940546

Specification specified the output type for quantized average pool should be
an i32. Only accumulator should be an i32, result type should match the input
type.

Caused in https://reviews.llvm.org/D111590

Reviewed By: sjarus, GMNGeoffrey

Differential Revision: https://reviews.llvm.org/D112484

Fixes https://github.com/clangd/clangd/issues/906

Differential Revision: https://reviews.llvm.org/D112403

The hack is irrelevant for two reasons:

* binutils 2.24 is quite old and cannot handle R_X86_64_REX_GOTPCRELX from 2016 onwards anyway
* `canMergeToProgbits` allows combining SHT_INIT_ARRAY/SHT_FINI_ARRAY into SHT_PROGBITS

Reviewed By: grokos

Differential Revision: https://reviews.llvm.org/D112475

The test was intended to also check the IR to be empty.

[LegalizeTypes][TargetLowering] Merge getShiftAmountTyForConstant into TargetLowering::getShiftAmountTy.

getShiftAmountTyForConstant is a special helper that changes the
shift amount to i32 if the type chosen by
TargetLowering::getShiftAmountTy can't represent all possible values.
This is needed to satisfy an assert in SelectionDAG::getNode.

It requires additional consideration to know when this helper should be used.
I'm not sure that we are always using it when we should.

This patch merges the getShiftAmountTyForConstant handling into
TargetLowering::getShiftAmountTy so we don't need to think about it
anymore.

Technically this may slightly increase compile times since the majority
of callers of getShiftAmountTy won't need this. Hopefully, this isn't
an issue in practice.

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D112469

Remove a couple of uses of expectedToOptional() in FileManagerTest,
using Expected<T>::moveInto() to extract the value instead instead.

Always insert values into ExprValueMap, and instead skip using them
in SCEVExpander if poison-generating flags have been lost. This
ensures that all values that are in ValueExprMap are also in
ExprValueMap, so we can use the latter to invalidate the former.

This change is probably not entirely NFC for the case where
originally the SCEV had no nowrap flags but they were inferred
later, in which case that would now allow reusing the existing
value for expansion.

Differential Revision: https://reviews.llvm.org/D112389

Fixes PR52292.

Reviewed By: asbirlea

Differential Revision: https://reviews.llvm.org/D112473

Fixes link errors.

Remove extra `/` in path to match the include filepath from the previous
line.

Differential Revision: https://reviews.llvm.org/D112476

Differential Revision: https://reviews.llvm.org/D112477

Part of work to have the LLVM backend to use more inclusive terms.

Reviewed By: reames

Differential Revision: https://reviews.llvm.org/D112461

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D112482

For a function call (using the default `-fplt`), GCC `-mcmodel=large` generates an assembly modifier which
leads to an R_X86_64_PLTOFF64 relocation. In real world,
http://git.ageinghacker.net/jitter (used by GNU poke) uses `-mcmodel=large`.

R_X86_64_PLTOFF64's formula is (if preemptible) `L - GOT + A` or (if non-preemptible) `S - GOT + A`
where `GOT` is (confusingly) the address of `.got.plt`

Reviewed By: peter.smith

Differential Revision: https://reviews.llvm.org/D112386

Taken from Chih-Mao Chen's D100835.

RelExpr has 64 bits now and needs the extension to support new members
(`R_PLT_GOTPLT` for `R_X86_64_PLTOFF64` support).

Note: RelExpr needs to have at least a member >=64 to prevent
-Wtautological-constant-out-of-range-compare for `if (expr >= 64)`.

Reviewed By: arichardson, peter.smith

Differential Revision: https://reviews.llvm.org/D112385

Reviewed By: sammccall

Differential Revision: https://reviews.llvm.org/D112209

Rewrite some comments as appropriate.