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

This temporarily reverts commit
60bee9ff.
The diff will be recommitted once the newly discovered
regressions are fixed.

A "null" designator won't have a valid location. Try to approximate this
location as best we can in that situation.

Closes 61118
Closes 46132

Reviewed By: shafik

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

Some tests were accidentally removed due to debug code being included.
Readding the tests to guarantee coverage.

Reviewed By: NatashaKnk

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

This check will look for usages of standard library type traits of the form `traits<...>::type` and `traits<...>::value` and convert them into `traits_t<...>` and `traits_v<...>` respectively.
This expands on the work in D135404 by supporting dependent traits with no instantiations as well as types.

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

Previously there were several attempts to make the format checks for NaN
and Inf work across platforms, like AIX and Solaris, that print these
values slightly differently. This resulted in a number of forward fixes,
until we finally disabled the tests for NaN and Inf. This change should
make the test robust across different platforms, and reduce the overall
amount of code by delegating to helper functions that use the same
format strings as the implementations used by PrintNumber().

This additionally reverts commit 5a9bad17
and fa56e362.

Reviewed By: jhenderson

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

These changes make it possible to use __synth_three_way in modules. The
change from a lambda to a function is a Clang issue.

The change is list was needed since the compiler couldn't deduce the
comparison template argument.

Adds a few missing includes too.

Reviewed By: #libc, ldionne

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

In commit cffadbd951e9 the test I added was using a C++17 feature and this
breaking some build bots. I don't need the feature and so I will modify
the test to not use it.

PR D135370 implemented a performance improvement but it restricted the filtering
of declaration from inline namespace too much. In particular it did not filter
for the function template case.

This led to a regression and this PR removes that check.

This fixes: https://github.com/llvm/llvm-project/issues/61851

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

  LWG3842 Unclear wording for precision in chrono-format-spec

Note there is nothing to do, the issue clarifies the wording in the Standard.
The new wording matches my interpretation of the previous wording and this has
already been implemented in libc++.

Reviewed By: #libc, ldionne

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

This reduces the number of transitive includes when using format.

Reviewed By: #libc, ldionne

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

This has been done using the following command

  find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)(?<!::u)u?intmax_t)|\1std::\2|' \{} \;

The std module doesn't export declarations in the global namespaace.
This is a preparation for that module.

Reviewed By: #libc, ldionne

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

This patch is primarily about the change in
"mlir/tools/mlir-cpu-runner/CMakeLists.txt". LLJIT needs access to
symbols (e.g. llvm_orc_registerEHFrameSectionWrapper) that will be
defined in the executable when LLVM is linked statically. This change is
consistent with how other tools within LLVM use LLJIT. It is required to
make sure that:
```
 $ mlir-cpu-runner --host-supports-jit
```
correctly returns `true` on platforms that do support JITting (in my
case that's AArch64 Linux).

The change in "mlir/lib/ExecutionEngine/CMakeLists.txt" is required to
avoid ODR violations when symbols from `mlir-cpu-runner` are exported
and when loading `libmlir_async_runtime.so` in `mlir-cpu-runner`.
Specifically, to avoid `EnableABIBreakingChecks` being defined twice.
For more context:
  * https://github.com/llvm/llvm-project/issues/61712
  * https://github.com/llvm/llvm-project/issues/61856
  * https://reviews.llvm.org/D146935 (this PR)

This change relands ccdcfad0

Fixes #61856

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