Running check-clang-tools on Windows produces 5 test failures:

Failed Tests (5):
  Clang Tools :: clang-apply-replacements/ClangRenameClassReplacements.cpp
  Clang Tools :: clang-apply-replacements/basic.cpp
  Clang Tools :: clang-apply-replacements/format.cpp
  Clang Tools :: clang-move/move-used-helper-decls.cpp
  Clang Tools :: clang-tidy/infrastructure/export-diagnostics.cpp

Four of these failures are simply due to fixed character position
offsets differing on Windows versus Linux, since Windows line endings
take up two characters instead of one:

clang-apply-replacements/ClangRenameClassReplacements.cpp runs clang-rename -offset=254
clang-apply-replacements/Inputs/basic/file[12].yaml specify e.g.  FileOffset: 148 and Offset: 298
clang-apply-replacements/Inputs/format/{no,yes}.yaml specify e.g.  FileOffset: 94 and Offset: 94
clang-tidy/infrastructure/export-diagnostics.cpp specifies e.g.  CHECK-YAML-NEXT: FileOffset: 30

(The move-used-helper-decls.cpp failure seems more complex; clang-move
adds a blank line after void HelperFun1() {} when
clang-move/Inputs/helper_decls_test.cpp has LF line endings, but does
not add a blank line when the input files has CRLF line endings. That
difference in behavior seems like it may be an actual bug, but I have
yet to track it down.)

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

As per https://bugs.llvm.org/show_bug.cgi?id=52119.

Reviewed By: myhsu

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

This relands commit b3b2538d, except that the new files in Support
are instead in a new library WindowsDriver.

With bc013b3e4e862da8d0c2d91cf99dcbebf124e4ac a new section called accessible functions was added to swift/include/swift/ABI/ObjectFile.h so this change adds support for dumping it out into the dSYM bundle

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

Adds missing header to fix sanitizer builds for Fuchsia.

Reviewed By: abrachet

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

elementtype is only allowed on caller arguments.

- Added an option where to put the requires clauses.
- Renamed IndentRequires to IndentRequiresClause.
- Changed BreakBeforeConceptDeclaration from bool to an enum.

Fixes https://llvm.org/PR32165, and https://llvm.org/PR52401.

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

Less typing than `-fprofile-instr-use`, and means the same thing.

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

Follow-up to 458ead66, which replaced the bespoke CMakeLists.txt
file for building a custom instrumented libc++ with an invocation of the
runtimes build.

In the the bespoke CMakeLists.txt, the LIBCXX_CXX_ABI setting was forced
to libcxxabi, but this was not done for the CMake invocation for the
runtimes build. This would cause CMake configuration issues on platforms
where the default LIBCXX_CXX_ABI setting is not libcxxabi, such as
FreeBSD.

Add `-DLIBCXX_CXX_ABI=libcxxabi` to that invocation, to make sure the
custom instrumented libc++ always uses the expected ABI.

Reviewed By: phosek

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

This reverts commit b3b2538d,
it introduced a cycklic module depenency that broke the -DLLVM_ENABLE_MODULES=1 build.

Remove most calls to deprcated Address constructor in CGExpr.cpp

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

An infinite loop without any effects is illegal C++ and can be optimized
away by the compiler.

Reviewed By: vitalybuka

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

This reverts commit 2722ac65. As explained in D115906, this was actually
unnecessary and it broke the external threading configuration.

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

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

If we can prove that an addition without wrap flags won't wrap, decompse
the operation.

Issue #48253

This should silence all remaining clang-cl build warnings.

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

This is reduced from a test that failed with D118376.
The C source is posted in issue #53695

The addresses matter - we want to verify the splitting
and order of the memops.

This works around a known issue in ASan. ASan doesn't instrument weak
symbols. Because instrumentation increases object size, the binary can
end up with two versions of the same object, one instrumented and one
not instrumented, with different sizes, which ASan will report as an ODR
violation. In libc++, this affects typeinfo for `std::bad_function_call`
which is emitted as a weak symbol in the test executable and as a strong
symbol in the shared library.

The main open issue for ASan appears to be
https://github.com/google/sanitizers/issues/1017.

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

Fix up includes after 595d340d
("sanitizer_common: make internal/external headers compatible").

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

This mechanism was used for a couple of purposes, but the primary one was keeping track of which predicates in a union might apply to an expression.  As these sets are small and agressively deduped, this has little value.

Requires keeping better track of sret types.

for sequence of character types.

Upstream type test. Upstream test. Fix tests.

Do not run on windows, as that is not an implemented target.

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

Reviewed By: eugenis

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

Even if the search is marked as terminated after only looking at
the first operand, we'd still look at the remaining operands
before actually ending the search.

This seems pointless and wasteful, let's not do that.

Since we don't greedily flatten `umin_seq(a, umin(b, c))` into `umin_seq(a, b, c)`,
just looking at the operands of the outer-level `umin` is not sufficient,
and we need to recurse into all same-typed `umin`'s.

That is the canonical expansion for umin_seq,
so we really should roundtrip it.

The current logic was: https://alive2.llvm.org/ce/z/j8muXk
but in reality the offset to the Y in the 'true' hand
does not need to exist: https://alive2.llvm.org/ce/z/MNQ7DZ
https://alive2.llvm.org/ce/z/S2pMQD

To catch that, instead of computing the Y's in both
hands and checking their equality, compute Y and C,
and check that C is 0 or 1.

Apparently we didn't have any tests for that codepath?

Pulled out of D106237, this replaces the X86ISD::AVG DAG node with the
generic ISD::AVGCEILU. It doesn't remove the detectAVGPattern method,
but the extra generic ISel matching does alter the existing test.

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

Reviewed By: eugenis

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