Function and variable names are not detected when there is a
__attribute__((x)) preceding the name.

Fixes #64137.

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

Add helper that creates a lambda similar to typeIs, but containing the
predicate check for hasStdExtF and hasStdD. We can use this with legalIf
and all to reduce the number of manual lambdas we need to write.

Fixing fir::unwrapSeqOrBoxedSeqType check for fir::BaseBoxType to add
support for fir::BoxType and fir::ClassType

[ARC][Documentation] Explicitly state that messaging weak objects keeps a strong reference during call lifetime (#72169)

rdar://113636046

This patch infers `nneg` flags for existing zext instructions in SCCP.

Similar patch: https://github.com/llvm/llvm-project/pull/72052

Use MCAsmBackend::writeNopData() interface to emit NOP instructions on
x86. There are multiple forms of NOP instruction on x86 with different
sizes. Currently, LLVM's assembly/disassembly does not support all forms
correctly which can lead to a breakage of input code semantics, e.g. if
the program relies on NOP instructions for reserving a patch space.

Add "--keep-nops" option to preserve NOP instructions.

When this option gets enabled, descriptions of stack frames will be
generated using the format provided in the launch configuration instead
of simply calling `SBFrame::GetDisplayFunctionName`. This allows
lldb-dap to show an output similar to the one in the CLI.

This apparently shows up somewhere in chromium. We also are missing a
canonicalization to an equality compare with inf.

This test is currently only enabled for X86 target.

Since system modules don't emit most warnings, remove the warning flags
to increase module reuse.

When a BLOCK construct is within an ASSOCIATE or related construct,
don't misinterpret an assignment to an array element of a construct
entity as being an impermissible definition of a local statement
function.

https://github.com/llvm/llvm-project/issues/72157

It is possible to declare the rank of an object after that object has
been used in the same specification part in a specification function
reference whose result or generic resolution may well have depended on
the object being apparently a scalar.

Catch this case, and emit a warning -- not an error, yet, due to fear of
false positives.

See the new test for examples.

Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair number of
sites in the code do not, and can emit portability warnings
unconditionally, which can confuse a user that hasn't asked for them
(-pedantic) and isn't terribly concerned about portability *to* other
compilers.

Add calls to ShouldWarn() or IsEnabled() around messages that need them,
and add -pedantic to tests that now require it to test their portability
messages, and add more expected message lines to those tests when
-pedantic causes other diagnostics to fire.

Compilation-time subscript value range checking should emit a warning,
not an error, when the indexed array is a dummy argument; there's
old-school codes out there that should have used assumed-size dummy
arguments but didn't.

Per the spec, "Before version 1.4, results are only computed per
component." So using scalar condition to select composite needs SPIR-V
v1.4 at least.

Fortran free form line continuation with '&' works with this compiler
even across the end of an included source file, as it does with most
other Fortran compilers. This extension should be documented.

I explicitly skipped definability checking for construct entities under
a RANK() clause. I don't know what I was thinking at the time; it's
obviously incorrect! Fix, and add tests.

https://github.com/llvm/llvm-project/issues/72157

These should have been part of e0e0891d

typeIs and LegalizeMutation::changeTo instead of implementing our own lambdas
that do the same thing.

During function-like macro expansion in a standard C/C++ preprocessor,
the macro being expanded is disabled from recursive macro expansion. The
implementation in this compiler's preprocessor, however, was too broad;
the macro expansion needs to be disabled for the "rescanning" phase
only, not for actual argument expansion.

(Also corrects an obsolete comment elsewhere that was noticed during
reduction of an original test case.)

A NULL() pointer without MOLD= cannot be allowed to be associated with
an assumed-rank dummy argument, as its rank is not well-defined and
neither the RANK() intrinsic function or the SELECT RANK construct will
work in the callee.

When the bounds of a substring reference are known during compilation,
and are outside the valid range for the character base object, issue an
error message.

In Fortran, a format automatically repeats, with a line break, until all
the data items of a data transfer statement have been consumed. PRINT
"(3I4)", 1, 2, 3, 4, 5, 6 prints two lines, for example, three values
each.

When there are nested parentheses in a format, the rightmost set of
parentheses at the top level are used for automatic repetition. PRINT
"(I4,2(I4))" 1, 2, 3, 4, 5, 6, 7 print three lines, with three values on
the first and two each on the later ones.

Fix a bug in format interpretation that causes the detection of the
"rightmost" set of parentheses to take place on each pass, leading to
problems when parentheses are even further nested.

…forwarded to CONTIGUOUS dummy

No object with the ASYNCHRONOUS or VOLATILE attribute can go through the
copy-in/copy-out protocol necessary for argument association with a
contiguous dummy array argument. The check for this constraint missed
the case of an assumed-rank array without an explicit CONTIGUOUS
attribute being forwarded on to a CONTIGUOUS dummy argument.

This reverts commit 7b94744e.

This breaks the expensive checks bot: https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/26026/

We didn't notice because it was broken for other reasons I think.

When NOP instructions are used to reserve space in the code, e.g. for
patching, it becomes critical to preserve their original size while
emitting the code. On x86, we rely on "Size" annotation for NOP
instructions size, as the original instruction size is lost in the
disassembly/assembly process.

This change makes instruction size a first-class annotation and is
affectively NFCI. A follow-up diff will use the annotation for code
emission.

An assumed-rank array may not be a coarray and may not have the VALUE
attribute.

The SIZE= specifier may not appear on a list-directed or namelist READ
statement.

These intrinsic functions are not particularly valuable -- one can just
compare a value to IOSTAT_END or IOSTAT_EOR directly -- but they are in
the standard and are allowed to appear in constant expressions, so
here's code to fold them.

This uses YAML anchors to deduplicate a lot of the pipeline LOC.

This makes it a lot easier to navigate through the file and to make modifications.

The dummy argument names used for the interface to C_ASSOCIATED() were
wrong.

Looks like an incomplete fixup was done after copying the umin/umax tests.