This was causing two test failures when I applied D129208 to enable
extra verification of LiveIntervals:

  LLVM :: CodeGen/AMDGPU/optimize-negated-cond-exec-masking-wave32.mir
  LLVM :: CodeGen/AMDGPU/optimize-negated-cond-exec-masking.mir

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

Directly test the 5 overloaded types instead of doing extra
set creation and iteration.

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

This caused the reported errors from the Call*() handlers to report the
wrong source location.

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

Outlining isn't always a win when the saved instruction count is >= 1.
The overhead of representing a new function in the binary depends on
exception metadata and alignment. So parameterize this for local tuning.

Reviewed By: paquette

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

Partially fixed [#60035](https://github.com/llvm/llvm-project/issues/60035)
This patch refactor the FixHint for concat-nest-namespace.
1. remove each namespace except the last non-nest namespace.
2. replace the last non-nest namespace with the new name.

It can remain the comment / pragma / macro between namespace and update the close comment.

Reviewed By: PiotrZSL

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

This test was removed as LLJIT now reflects process symbols by default.

Use clone to keep the metadata, the issue is reported
by aeubanks on D141188.

Reviewed By: nikic, paulwalker-arm

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

This reapplies 371cb1af, which was reverted in 0b2240ed due to bot
failures.

The clang-repl test failure is fixed by dropping the process symbols definition
generator that was manually attached to the main JITDylib, since LLJIT now
exposes process symbols by default. (The bug was triggered when JIT'd code used
the process atexit provided by the generator, rather than the JIT atexit which
has been moved into the platform JITDylib).

Any LLJIT clients that see crashes in static destructors should likewise remove
any process symbol generators attached to their main JITDylib.

Reviewed By: Peiming

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

Attempt to fix issue #61761

Add missing new line for `llvm/docs/CommandGuide/llvm-remarkutil.rst`

This reverts commit 0f7fcb4c.

This reverts commit 7cc80ef5.

[clang:diagnostics] Turning off warn_self_assignment_overloaded for user-defined compound assignments

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

Only check self assignment on BO_Assign when BuildOverloadedBinOp.

This adds a `annotation-count` option to llvm-remarkutil.

```
llvm-remarkutil annotation-count -remark=REMARK
```
This will print out the remark count for a pass that uses annotation remarks.

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

This patch introduces UPCStandalonePointerGadget, a FixableGadget that emits fixits to
handle cases where a pointer identified as unsafe is simply referenced. An example of
such a case is when the pointer is input as an argument to a method call, where we can
not change the type of the argument. For cases where the strategy for the unsafe pointer is
to use std::span, the idea is to extract the underlying pointer by invoking the "data()"
method on the span instance.

For example, the gadget emits a fixit for S3, where S1, S2 are handled by other gadgets:
  S1: int *ptr = new int[10];
  S2: int val1 = ptr[k]; // Unsafe operation on ptr
  S3: foo(ptr); // Some method that accepts raw pointer => FIXIT: foo(ptr.data());

Reviewed by: NoQ, ziqingluo-90, jkorous

Differential revision: https://reviews.llvm.org/D143676

Fused multiply and add are being pushed directly to the libm. This is problematic
for situations where libm is not available. This patch will break down a fused multiply and
add into a multiply followed by an add.

Reviewed By: rsuderman

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

Apple added a new NS_ERROR_ENUM macro to help define enums for
NSError codes.

This updates libformat's Objective-C language-guessing heuristic
to detect the new macro as well as related NSError types.

Tested: New tests added.

Reviewed By: MyDeveloperDay

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

Currently, when we send an address to atos to be symbolized, it is
expected that atos returns with more than it was sent, i.e. symbol
information for that address. In the case where only the address is
returned, we currently null the pointer to the atos process. Typically,
for modules where no symbolication is expected, we do not send the
address to atos.

However, in new simulators there is an early call that atos does not
return any symbol information for. And in this case, because we have
gotten rid of the pointer to the process, no subsequent frames are
symbolicated, even tho atos is still working/running.

This patch removes the nulling of the pointer to the process. This
allows subsequent calls to atos even after an unexpected result.
It also now Reports what has happened and the address this occurred.

This will improve symbolication in cases where we get an unepxected
result, and will make it easier to diagnose atos if it is not
symbolicating as expected.

Filed a radar about the change of behavior 107621524

rdar://107169715

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

Somehow this test has been left behind in my sandbox. This
patch adds a lowering test for fir.select_type operation and
makes sure the dynamic type comaparison is done in the right
order when we have multiple CLASS IS type guard statement
for types that are linked.

This should have been posted with D138280.

Reviewed By: PeteSteinfeld

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

This is mostly useful for ARM64EC, which uses such symbols extensively.

One interesting quirk of ARM64EC is that we need to be able to emit weak
symbols that point at each other (so if either symbol is defined
elsewhere, both symbols point at the definition).  This required a few
changes to the way we handle weak symbols on Windows.

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

Fix uninitialized variable warning when deserializing a std::optional<E>
where is an enum type.

JSON.h:771:20: warning: variable 'Result' is uninitialized when used here [-Wuninitialized]
  if (!fromJSON(E, Result, P))
                   ^~~~~~

This adds tests for:
- FileSpec::TestFileNameExtensions
- FileSpec::TestFileNameStrippingExtension
- FileSpec::IsSourceImplementationFile

This additionally updates incorrect documentation.

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

        Reported by Coverity:

        Big parameter passed by value
        Copying large values is inefficient, consider passing by reference; Low, medium, and high size thresholds for detection can be adjusted.

       1. Inside "SemaConcept.cpp" file, in subsumes<clang::Sema::MaybeEmitAmbiguousAtomicConstraintsDiagnostic(clang::NamedDecl *, llvm::ArrayRef<clang::Expr const *>, clang::NamedDecl *, llvm::ArrayRef<clang::Expr const *>)::[lambda(clang::AtomicConstraint const &, clang::AtomicConstraint const &) (instance 2)]>(llvm::SmallVector<llvm::SmallVector<clang::AtomicConstraint *, 2u>, 4u>, llvm::SmallVector<llvm::SmallVector<clang::AtomicConstraint *, 2u>, 4u>, T1): A large function call parameter exceeding the low threshold is passed by value.

        i. pass_by_value: Passing parameter PDNF of type NormalForm (size 144 bytes) by value, which exceeds the low threshold of 128 bytes.

        ii. pass_by_value: Passing parameter QCNF of type NormalForm (size 144 bytes) by value, which exceeds the low threshold of 128 bytes.

        2. Inside "CodeGenAction.cpp" file, in clang::reportOptRecordError(llvm::Error, clang::DiagnosticsEngine &, clang::CodeGenOptions): A very large function call parameter exceeding the high threshold is passed by value.

        i. pass_by_value: Passing parameter CodeGenOpts of type clang::CodeGenOptions const (size 1560 bytes) by value, which exceeds the high threshold of 512 bytes.

        3. Inside "SemaCodeComplete.cpp" file, in HandleCodeCompleteResults(clang::Sema *, clang::CodeCompleteConsumer *, clang::CodeCompletionContext, clang::CodeCompletionResult *, unsigned int): A large function call parameter exceeding the low threshold is passed by value.

        i. pass_by_value: Passing parameter Context of type clang::CodeCompletionContext (size 200 bytes) by value, which exceeds the low threshold of 128 bytes.

        4. Inside "SemaConcept.cpp" file, in <unnamed>::SatisfactionStackRAII::SatisfactionStackRAII(clang::Sema &, clang::NamedDecl const *, llvm::FoldingSetNodeID): A large function call parameter exceeding the low threshold is passed by value.

        i. pass_by_value: Passing parameter FSNID of type llvm::FoldingSetNodeID (size 144 bytes) by value, which exceeds the low threshold of 128 bytes.

        Reviewed By: erichkeane, aaron.ballman

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

Using the more robust log2 search allows us to fold more cases (same
logic as exists for idiv/irem).

Reviewed By: nikic

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

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

Add MultiLevelTemplateArgumentList::dump
(similarly to TemplateArgument::dump).

Differential revision: https://reviews.llvm.org/D147744

`expContainsTensor` used to call `expIsTensor` to short-circuit the recursive calls; however, the very first thing `expContainsTensor` does is to check `expIsTensor`, so the short-circuiting code just causes the function to check that condition redundantly.

Depends On D146684

Reviewed By: aartbik

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

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

SelectMostRelevantFrame triggers the StackFrameRecognizer construction,
which can run arbitrary Python code, call expressions etc. WillStop gets
called on every private stop while the recognizers are a user-facing
feature, so first off doing this work on every stop is inefficient. But
more importantly, you can get in to situations where the recognizer
causes an expression to get run, then when we fetch the stop event at
the end of the expression evaluation, we call WillStop again on the
expression handling thread, which will do the same StackFrameRecognizer
work again. If anyone is locking along that path, you will end up with a
deadlock between the two threads.

The example that brought this to my attention was the
objc_exception_throw recognizer which can cause the objc runtime
introspection functions to get run, and those take a lock in
AppleObjCRuntimeV2::DynamicClassInfoExtractor::UpdateISAToDescriptorMap
along this path, so the second thread servicing the expression deadlocks
against the first thread waiting for the expression to complete.

It makes more sense to have the frame recognizers run on demand, either
when someone asks for the variables for the frame, or when someone does
GetSelectedFrame. The former already worked that way, the only reason
this was being done in WillStop was because the StackFrameRecognizers
can change the SelectedFrame, so you needed to run them before the
anyone requested the SelectedFrame.

This patch moves SelectMostRelevantFrame to StackFrameList, and runs it
when GetSelectedFrame is called for the first time on a given stop. If
you call SetSelectedFrame before GetSelectedFrame, then you should NOT
run the recognizer & change the frame out from under you. This patch
also makes that work. There were already tests for this behavior, and
for the feature that caused the hang, but the hang is racy, and it
doesn't trigger all the time, so I don't have a way to test that
explicitly.

One more detail: it's actually pretty easy to end up calling
GetSelectedFrame, for instance if you ask for the best ExecutionContext
from an ExecutionContextRef it will fill the StackFrame with the result
of GetSelectedFrame and that would still have the same problems if this
happens on the Private State Thread. So this patch also short-circuits
SelectMostRelevantFrame if run on the that thread. I can't think of any
reason the computations that go on on the Private State Thread would
actually want the SelectedFrame - that's a user-facing concept, so
avoiding that complication is the best way to go.

rdar://107643231

Differential revision: https://reviews.llvm.org/D147753

dependencies.

Improved compiled time by the precomputing the mapping between gathered
scalars and their gather/buildvector nodes for later use in
isGatherShuffledEntry to avoid recomputing this map each time this
function is called.

This adds a list of attributes which can be pretty to be able to reject attributes which were introduced in a later C++ standard.
Fixes #61196

Reviewed By: Mordante, #libc

Spies: mikhail.ramalho, jdoerfert, libcxx-commits

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

In the Fortran standard 2018 section 10.2.1.3 (13), it is mentioned
that all noncoarray allocatable component must follow this sequence of
operations:

1) If the component of the variable is allocated, it is deallocated.
2) If the component of the value of expr is allocated, the corresponding
   component of the variable is allocated with the same dynamic type and
   type parameters as the component of the value of expr. If it is an
   array, it is allocated with the same bounds. The value of the
   component of the value of expr is then assigned to the corresponding
   component of the variable using defined assignment if the declared type
   of the component has a type-bound defined assignment consistent with the
   component, and intrinsic assignment for the dynamic type of that component
   otherwise.

This patch updates the code to make use of the user defined assignment for
allocatable component and make sure the component is allocated correctly.

Reviewed By: klausler

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