This intrinsic was missing from the list the predicate checks a module
for in order to determine if ARC passes need to run. This results in
instruction selection failure if this instrinsic is left behind.

Add the intrinsic to the predicate to fix.

- Replace custom predicate for arc intrinsics in a module with existing
  ModuleHasARC
- Remove unused include introduced by earlier commit

- Include Pass in default codegen pipeline
- Delete all other places the pass is added
- Bail early if no arc Intrinsics are found in the module

- Adjust test
- Unconditionally include ARC pass in ThinLTO pipeline

Prior to this patch, when using -fthinlto-index= the
ObjCARCContractPass isn't run prior to CodeGen, and
instruction selection fails on IR containing
arc intrinstics.

This was an oversight in #91859. Using the subblock ID mechanism
other places that use the bitstream APIs (e.g. `BitstreamRemarkSerializer`) use.

The `--temporal-profile-max-trace-length=0` flag in the `llvm-profdata
merge` command is used to remove traces from a profile. There was a bug
where traces would not be cleared if the profile was already sampled.
This patch fixes that.

When the MOLD= argument's type is polymorphic, the type of the result
cannot be known at compilation time, so the call cannot be folded even
when the SOURCE= is constant.

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

A !$CUF KERNEL DO directive is allowed to have advisory REDUCE clauses
similar to those in OpenACC and DO CONCURRENT. Parse and represent them.
Semantic validation will follow.

When a BIND(C) interface or subprogram has a dummy argument whose
derived type is not BIND(C) but meets the constraints and requirements
of a BIND(C) type, accept it with a warning.

When a procedure is defined with a subprogram but never referenced in a
compilation unit, it may not be characterized until lowering, and any
errors in characterization then may crash the compiler. So always ensure
that procedure definitions are characterizable in declaration checking.

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

This allows the warning to be disabled in isolation, as it helps when
treating them as errors.

ELEMENTAL internal subprograms are pure unless explicitly IMPURE.

[Clang][Sema] Do not mark template parameters in the exception specification as used during partial ordering (#91534)

We do not deduce template arguments from the exception specification
when determining the primary template of a function template
specialization or when taking the address of a function template.
Therefore, this patch changes `isAtLeastAsSpecializedAs` such that we do
not mark template parameters in the exception specification as 'used'
during partial ordering (per [temp.deduct.partial]
p12) to prevent the following from being ambiguous:

```
template<typename T, typename U>
void f(U) noexcept(noexcept(T())); // #1

template<typename T>
void f(T*) noexcept; // #2

template<>
void f<int>(int*) noexcept; // currently ambiguous, selects #2 with this patch applied 
```

Although there is no corresponding wording in the standard (see core issue filed here
https://github.com/cplusplus/CWG/issues/537), this seems
to be the intended behavior given the definition of _deduction
substitution loci_ in [temp.deduct.general] p7 (and EDG does the same thing).

This option is a compilation action that parses a source file and
performs semantic analysis on it, like the existing -fdebug-unparse
option does. Its output, however, is preceded by the effective contents
of all of the non-intrinsic modules on which it depends but does not
define, transitively preceded by the closure of all of those modules'
dependencies.

The output from this option is therefore the analyzed parse tree for a
source file encapsulated with all of its non-intrinsic module
dependencies. This output may be useful for extracting code from large
applications for use as an attachment to a bug report, or as input to a
test case reduction tool for problem isolation.

Update the publisher and add a publish script that we can use from
Github actions.

Most violations are stale and should be removed while a few can be
adjusted.

Reported at #92238

`ArrayInitLoopExpr` AST node has two occurences of its as-written
initializing expression in its subexpressions through a non-unique
`OpaqueValueExpr`. It causes double-visiting of the initializing
expression if not handled explicitly, as discussed in #85837.

This avoids visiting `co_await` or `co_yield` operand 5 times (it is
repeated under transformed awaiter subexpression, and under
`await_ready`, `await_suspend`, and `await_resume` generated call
subexpressions).

This also fixes building ... on Linux. Seems like target_compatible_with
isn't enough but you also need a manual tag.

Reverts llvm/llvm-project#91334

This broke the gcc7 build.
I suspect the issue is a mismatch on user-defined move constructor on
the return: `return PreservedGVs;` does not match the return type of the
function.

These are allowed for Darwin and use the same ABI.

Re-apply https://github.com/llvm/llvm-project/pull/81196, with a fix that handles the 
absence of llvm formatting: 
https://github.com/llvm/llvm-project/pull/91868/commits/3ba650e91eded3543764f37921dcce3b
b47d425f

Just as we do for the arrays of extension names.

Summary:
These are lots of random warnings due to inconsistent initialization or
signedness.

They *are* still accepted by the HW but have a conservative effect.

Leave them untouched since handling them would complicate the logic a
bit, and developers who code to such a low level really need to revisit
what they're doing anyway.

This PR adds a string interface to `InternalizePass`' `MustPreserveGV`
option, which is a callback function to indicate if a GV is not to be
internalized. This is for use in LLVM.jl, the Julia wrapper for LLVM,
which uses the C API and is thus required to use the PassBuilder string
API for building NewPM pipelines.

Assume in fewer places that the analysis is of a `FunctionDecl`, and
initialize the `Environment` properly for `Stmt`s.

Moves constructors for `Environment` to header to make it more obvious
that there are only minor differences between them and very little
initialization in the constructors.

Tested with check-clang-tooling.

As discussed in the last sync-up call, because these profiles are not
yet finalised they shouldn't be exposed to users unless they opt-in to
them (much like experimental extensions). We may later want to add a
more specific flag, but reusing `-menable-experimental-extensions`
solves the immediate problem.

This is implemented using the new support for marking profiles s
experimental added in #91993 to move the unratified profiles to
RISCVExperimentalProfile and making the necessary changes to logic in
RISCVISAInfo to handle this.

This reverts commit 2c54bf49.

Fixed gcc-7 issue.

Fixes #92193.

Summary:
If the user does not have the selected backend enabled, we should still
be able to build the LLVM-IR an ddistribute it. This patch makes logic
to suppress tests if the backend can't build it, as well as removing a
flag for the building that's only present int he NVPTX backend.

This patch covers the following Core issues:
[CWG930](https://cplusplus.github.io/CWG/issues/930.html) "`alignof`
with incomplete array type"
[CWG1110](https://cplusplus.github.io/CWG/issues/1110.html) "Incomplete
return type should be allowed in `decltype` operand"
[CWG1340](https://cplusplus.github.io/CWG/issues/1340.html) "Complete
type in member pointer expressions"
[CWG1352](https://cplusplus.github.io/CWG/issues/1352.html)
"Inconsistent class scope and completeness rules"
[CWG1458](https://cplusplus.github.io/CWG/issues/1458.html) "Address of
incomplete type vs `operator&()`"
[CWG1824](https://cplusplus.github.io/CWG/issues/1824.html)
"Completeness of return type vs point of instantiation"
[CWG1832](https://cplusplus.github.io/CWG/issues/1832.html) "Casting to
incomplete enumeration"
[CWG2304](https://cplusplus.github.io/CWG/issues/2304.html) "Incomplete
type vs overload resolution"
[CWG2310](https://cplusplus.github.io/CWG/issues/2310.html) "Type
completeness and derived-to-base pointer conversions"
[CWG2430](https://cplusplus.github.io/CWG/issues/2430.html)
"Completeness of return and parameter types of member functions"
[CWG2512](https://cplusplus.github.io/CWG/issues/2512.html) "`typeid`
and incomplete class types"
[CWG2630](https://cplusplus.github.io/CWG/issues/2630.html) "Syntactic
specification of class completeness"
[CWG2718](https://cplusplus.github.io/CWG/issues/2718.html) "Type
completeness for derived-to-base conversions"
[CWG2857](https://cplusplus.github.io/CWG/issues/2857.html)
"Argument-dependent lookup with incomplete class types"

Current wording for CWG1110 came from
[P0135R1](https://wg21.link/p0135R1) "Wording for guaranteed copy
elision through simplified value categories".

As a drive-by fix, I fixed incorrect status of CWG1815, test for which
was added in #87933. CC @yronglin