$0 can only be used as a tab stop, not as a placeholder (e.g.
`${0:expression}` is not valid)

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

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

This reverts commit d534967b.

The patch causes build failures, such as:

https://lab.llvm.org/buildbot/#/builders/121/builds/21760

The declaration was introduced without a corresponding definition on
Sep 7, 2020 in commit f5d07a05.

[libcxx] Remove static inline and make use of _LIBCPP_HIDE_FROM_ABI in __support/xlocale/__nop_locale_mgmt.h header

Reviewed By: ldionne

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

Identified with modernize-use-default-member-init

Fixes llvmorg-15-init-917-g46a6f5ae

Switching to std:array allow us to use fill.

While I am at it, this patch also converts one for loop to a
range-based one.

Following recent changes removing non-core features of the legacy
PM/optimization pipeline.

The last use was removed on Jan 4, 2022 in commit
95a93722.

ArrayRef has operator[], so we don't need to access the contents via
data().

Identified with readability-redundant-control-flow.

to match all other *ISelDAGToDAG.cpp

This patch also drops "&" that binds to a temporary.

Identified with readability-const-return-type.

Identified with modernize-use-default-member-init.

The predicate IsHostAssocited() was implemented in a way that would
return true only for cases of host association into a module or inner
subprogram.  Technically, the use of a name in a BLOCK construct
that is not declared therein is considered in the Fortran standard
to also be a form of host association, and this matters when doing
error checking on DATA statements.

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

We still haven't found a solution that correctly handles 'don't care' sub elements properly - given how close it is to the next release branch, I'm making this fail safe change and we can revisit this later if we can't find alternatives.

NOTE: This isn't a reversion of D128570 - it's the removal of undef handling across bitcasts entirely

Fixes #56520

When a procedure pointer with no interface is associated with
an EXTERNAL name with no interface information, but it is later
inferred that the procedure pointer must be a subroutine because it
appears in a CALL statement, don't complain that the EXTERNAL name
is not also known to be a subroutine.

Subroutine vs. function errors are still caught in procedure pointer
assignment compatibility checking; this fix simply ensures that those
more nuanced tests are not overridded by the attribute set equality test.

Also, leave in some code for dumping the differing attributes in legitimate
error cases that was added in the coures of debugging the specific problem.

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

In some contexts the code looks cleaner if we fold zero-length substring
references into empty character constants, but those don't work in
variable definition contexts and can lead to bogus semantic error
messages.

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

Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute." and follow-ups

This reverts commit 9429b67b.

It broke the build on Windows, see comments on https://reviews.llvm.org/D130309

It also reverts these follow-ups:

Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit f959d815.

Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit 0bbce7a4.

Revert "Cache the value for absolute path in FileSpec."
This reverts commit dabe8772.

It should be A= but I misspelled it in the intrinsics table as X=.

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

Follow up to D117977, where I missed this new usage after one rebase.

Thanks @tsteller in https://reviews.llvm.org/D117977#3670919 for
noticing.

Reviewed By: mstorsjo

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

Identified with misc-static-assert.

Previously, we treated it as a regular ConcatInputSection. However, ld64
actually parses its contents and uses that to synthesize a single image
info struct, generating one 8-byte section instead of `8 * number of
object files with ObjC code`.

I'm not entirely sure what impact this section has on the runtime, so I
just tried to follow ld64's semantics as closely as possible in this
diff. My main motivation though was to reduce binary size.

No significant perf change on chromium_framework on my 16-core Mac Pro:

             base           diff           difference (95% CI)
  sys_time   1.764 ± 0.062  1.748 ± 0.032  [  -2.4% ..   +0.5%]
  user_time  5.112 ± 0.104  5.106 ± 0.046  [  -0.9% ..   +0.7%]
  wall_time  6.111 ± 0.184  6.085 ± 0.076  [  -1.6% ..   +0.8%]
  samples    30             32

Reviewed By: #lld-macho, thakis

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

[X86] matchBinaryShuffle - limit SHUFFLE(X,Y) -> OR(X,Y) cases to where X + Y are the same width as the result

Minor bit of prep work toward not unnecessarily widening shuffle operands in combineX86ShufflesRecursively, instead only widening in combineX86ShuffleChain if we actual find a match - see Issue #45319

which occurs when there are EH frames present in the object file's weak
def.

Reviewed By: abrachet

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

This patch fixes the following error with MSVC 16.9.2:
llvm/lib/IR/GCStrategy.cpp(35): error C2668: 'llvm::report_fatal_error': ambiguous call to overloaded function
llvm/include/llvm/Support/ErrorHandling.h(75): note: could be 'void llvm::report_fatal_error(const llvm::Twine &,bool)'
llvm/include/llvm/Support/ErrorHandling.h(73): note: or 'void llvm::report_fatal_error(llvm::StringRef,bool)'
llvm/lib/IR/GCStrategy.cpp(35): note: while trying to match the argument list '(const std::string)'

Reviewed By: RKSimon, barannikov88

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

llvm::sort is beneficial even when we use the iterator-based overload,
since it can optionally shuffle the elements (to detect
non-determinism). However llvm::sort is not usable everywhere, for
example, in compiler-rt.

Reviewed By: nhaehnle

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

Reviewed By: MaskRay

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