[clang-tidy] checkOverridingFunctionReturnType - use castAs<> instead of getAs<> to avoid dereference of nullptr

The pointers are referenced immediately, so assert the cast is correct instead of returning nullptr

Revert "Reland "[lld/coff] Make lld-link work in a non-MSVC shell, add /winsysroot:""

This reverts commit 0574b5fc and 73e585e4.

This change is causing the test Driver/cl-options.c to fail on Windows buildbots.
https://lab.llvm.org/staging/#/builders/204/builds/1343

A LUI instruction with flag RISCVII::MO_HI is usually used in conjunction
with ADDI, and jointly complete address computation. To bind the cost
evaluation of address computation, the LUI should not be regarded as a cheap
 move separately, which is consistent with ADDI.

In this test case, it improves the unroll-loop code that the rematerialization
of array's base address miss MachineCSE with Heuristics #1 at isProfitableToCSE.

Reviewed By: asb, frasercrmck

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

Reviewed By: asb, frasercrmck

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

By unsetting this property, we are now able to internalize more symbols
during LTO. I compared the output of `-save-temps` for both LLD and
ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is
concerned.

(Thanks @smeenai for working on an initial version of this diff!)

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

Reviewed By: #lld-macho, thakis

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

Implements ADDS/SUBS 24-bit immediate optimization using the
MIPeepholeOpt pass. This follows the pattern:

Optimize ([adds|subs] r, imm) -> ([ADDS|SUBS] ([ADD|SUB] r, #imm0, lsl #12), #imm1),
if imm == (imm0<<12)+imm1. and both imm0 and imm1 are non-zero 12-bit unsigned
integers.

Optimize ([adds|subs] r, imm) -> ([SUBS|ADDS] ([SUB|ADD] r, #imm0, lsl #12), #imm1),
if imm == -(imm0<<12)-imm1, and both imm0 and imm1 are non-zero 12-bit unsigned
integers.

The SplitAndOpcFunc type had to change the return type to an Opcode pair so that
the first add/sub is the regular instruction and the second is the flag setting
instruction. This required updating the code in the AND case.

Testing:

I ran a two stage bootstrap with this code.
Using the second stage compiler, I verified that the negation of an ADDS to SUBS
or vice versa is a valid optimization. Example V == -0x111111.

Reviewed By: dmgreen

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

Move some combine patterns to DAG combine，and
it dealt with fixme left in RISCVInstrInfoZb.td.

Reviewed By: craig.topper

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

Reviewed By: browneee

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

It is generally an error when a USE-associated name clashes
with a name defined locally, but not in all cases; a generic
interface can be both USE-associated and locally defined.
This works, but not when there is also a local subprogram
with the same name, which is valid when that subprogram is
a specific of the local generic.  A bogus error issues at
the point of the USE because name resolution will have already
defined a symbol for the local subprogram.

The solution is to collect the names of local generics when
creating the program tree, and then create their symbols as
well if their names are also local subprograms, prior to any
USE association processing.

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

We are just grouping the files and the tests together.

Reviewed By: int3, #lld-macho

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

This diff has the C-string literals printed into the mapfile in the symbol table like how ld64 does.

Here is what ld64's mapfile looks like with C-string literals:
```
# Path: out
# Arch: x86_64
# Object files:
[  0] linker synthesized
[  1] foo.o
# Sections:
# Address       Size            Segment Section
0x100003F7D     0x0000001D      __TEXT  __text
0x100003F9A     0x0000001E      __TEXT  __cstring
0x100003FB8     0x00000048      __TEXT  __unwind_info
# Symbols:
# Address       Size            File  Name
0x100003F7D     0x0000001D      [  1] _main
0x100003F9A     0x0000000E      [  1] literal string: Hello world!\n
0x100003FA8     0x00000010      [  1] literal string: Hello, it's me\n
0x100003FB8     0x00000048      [  0] compact unwind info
```

Here is what the new lld's Mach-O mapfile looks like:
```
# Path: /Users/rgr/local/llvm-project/build/Debug/tools/lld/test/MachO/Output/map-file.s.tmp/c-string-liter
al-out
# Arch: x86_64
# Object files:
[  0] linker synthesized
[  1] /Users/rgr/local/llvm-project/build/Debug/tools/lld/test/MachO/Output/map-file.s.tmp/c-string-literal
.o
# Sections:
# Address       Size            Segment Section
0x1000002E0     0x0000001D      __TEXT  __text
0x1000002FD     0x0000001D      __TEXT  __cstring
# Symbols:
# Address           File  Name
0x1000002E0     [  1] _main
0x1000002FD     [  1] literal string: Hello world!\n
0x10000030B     [  1] literal string: Hello, it's me\n
```

Reviewed By: #lld-macho, int3

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

Reviewed By: eugenis

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

Reviewed By: eugenis

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

The __kmp_hidden_helper_threads_num set to N+1 if user requested N threads.
Thus number of worker hidden helper threads corresponds to user request,
main thread of helper team excluded as it does not participate in actual work.
This also fixes divide-by-0 issue in the code.

Fixes #48656

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

When a scope's symbol has characteriztics whose specification
expressions depend on other non-constant symbols in the same scope,
f18 rightfully emits an error.  However, in the case of usage in
specification expressions involving host association, the program is not
invalid.  This can arise, for example, in the case of an internal
function whose result's attributes use host-associated variables.

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

This reverts commit 0d9b9152.

This change broke LLDB's build. I will need to recommit after fixing LLDB.

There are several checks in the runtime routine for the RESHAPE
intrinsic.  Some checks verify things that should have been checked at
compile time while others represent user errors.

This update changes the checks for user errors into calls to "Crash"
which include information about the failing check.  This identifies them
as user errors rather than compiler errors.

I also verified that the checks that remain as internal errors are also
checked by the front end.  I added a test to the front end's RESHAPE
test to complete the checks.

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

Despite the comment saying `[[no_unique_address]]` on the `__base_` data member
makes clang crash, this does not seem to be true on CI. So, mark `__base_` with
`_LIBCPP_NO_UNIQUE_ADDRESS`.

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

Use the dyld_shared_cache_(un)pin_mapping SPI to map the whole shared
cache in memory (if possible) to avoid repeated calls to mmap.

rdar://81189015

This fixes Linux musl build after D118423.

- add some test cases for `cbegin`/`cend`;
- make class definitions generally follow the order in which they are
  used;
- add a missing include.

Reviewed By: philnik

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

This ensures that if we have a dbg.addr in a coroutine funclet that is on one of
our function arguments, that the dbg.addr is not mapped to undef and also that
later it isn't hoisted to the front of the basic block. Instead it remains at
its original cloned location.

rdar://83957028

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

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

Recently we observed high memory pressure caused by clang during some parallel builds.
We discovered that we have several projects that have a large number of #define directives
in their TUs (on the order of millions), which caused huge memory consumption in clang due
to a lot of allocations for MacroInfo. We would like to reduce the memory overhead of
clang for a single #define to reduce the memory overhead for these files, to allow us to
reduce the memory pressure on the system during highly parallel builds. This change achieves
that by removing the SmallVector in MacroInfo and instead storing the tokens in an array
allocated using the bump pointer allocator, after all tokens are lexed.

The added unit test with 1000000 #define directives illustrates the problem. Prior to this
change, on arm64 macOS, clang's PP bump pointer allocator allocated 272007616 bytes, and
used roughly 272 bytes per #define. After this change, clang's PP bump pointer allocator
allocates 120002016 bytes, and uses only roughly 120 bytes per #define.

For an example test file that we have internally with 7.8 million #define directives, this
change produces the following improvement on arm64 macOS: Persistent allocation footprint for
this test case file as it's being compiled to LLVM IR went down 22% from 5.28 GB to 4.07 GB
and the total allocations went down 14% from 8.26 GB to 7.05 GB. Furthermore, this change
reduced the total number of allocations made by the system for this clang invocation from
1454853 to 133663, an order of magnitude improvement.

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

fix code formatting

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

Previously, allocator functions were only available if they were included
from scudo or by using the system libc headers (i.e. by turning off the
full build). This patch changes the logic to include the prototypes for
the allocator functitons in all cases, which allows the linker to link
in the system's allocator.

Reviewed By: sivachandra, abrachet

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

All platforms return the main executable as the first dl_phdr_info.
FreeBSD, NetBSD, Solaris, and Linux-musl place the executable name
in the dlpi_name field of this entry. It appears that only Linux-glibc
uses the empty string.

To make this work generically on all platforms, unconditionally skip the first
object (like is currently done for FreeBSD and NetBSD). This fixes first DSO
detection on Linux-musl with clang -shared-libsan/-shared-libasan and GCC's
default. It also would likely fix detection on Solaris/Illumos if it were to
gain PIE support (since dlpi_addr would not be NULL).

Additionally, only skip the Linux VDSO on linux.

Finally, use the empty string as the "seen first dl_phdr_info"
marker rather than (char *)-1. If there was no other object, we
would try to dereference it for a string comparison.

Reviewed By: MaskRay, vitalybuka

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

This was missed in 8a0a706f (added
after that patch was made originally).

This reverts commit 19fdf85f.

This reverts commit 8f0e5b4e.

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.