Follow up to D134702; it looks like we were still warning for gnu89
mode.

Link: https://reviews.llvm.org/D134702
Link: https://github.com/ClangBuiltLinux/linux/issues/1720#issuecomment-1265738778

Reviewed By: aaron.ballman

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

The actual transformation doesn't support multi-output GenericOps, but
if we encounter one without sparse annotations we can just leave it
alone.

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

This patch provides `FileManager` with the CWD on construction in the worker, rather than later in the action.

Depends on D134976.

Reviewed By: benlangmuir

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

This patch removes the ability of a dependency scanning worker to share a `FileManager` instance between individual scans. It's not sound and doesn't provide performance benefits (due to the underlying caching VFS).

Reviewed By: benlangmuir

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

These are usually not interesting when clangd presents results in
context, and the file paths are noisy.

This patch lowers `TYPE(*)` correctly to fir.box<none>.

Reviewed By: jeanPerier

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

Since SROA chooses promotion based on reaching load / stores of allocas, we may run into scenarios in which we alloca a vector, but promote it to an integer. The result of which is the familiar LoadCombine pattern (i.e. ZEXT, SHL, OR). However, instead of coming directly from distinct loads, the elements to be combined are coming from ExtractVectorElements which stem from a shared load.

This patch identifies such a pattern and combines it into a load.

Change-Id: I0bc06588f11e88a0a975cde1fd71e9143e6c42dd

A very simple and minimal implementation of fork is added. Future
changes will add more functionality to satisfy POSIX and Linux
requirements.

An implementation of wait and a few support macros in sys/wait.h
have also been added to help with testing the fork function.

Reviewed By: lntue, michaelrj

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

Allow unknown types to pass through without being marked as illegal.

Reviewed By: antiagainst

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

As @mizvekov suggested in D134772. This works great for D128750 when
dealing with AutoType's.

Reviewed By: mizvekov, erichkeane

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

isOuterMostDepPositive()

The function isOuterMostDepPositive() is checked after negative dependence
vectors are normalized to be non-negative, so there will not be any negative
dependency ('>' as the outermost non-equal sign) after normalization. And
therefore the check in isOuterMostDepPositive() is irrelevent and redundant.

Reviewed By: congzhe

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

Reviewed By: aartbik

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

Turn it into a single Expr::isFlexibleArrayMemberLike method, as discussed in

        https://discourse.llvm.org/t/rfc-harmonize-flexible-array-members-handling

Keep different behavior with respect to macro / template substitution, and
harmonize sharp edges: ObjC interface now behave as C struct wrt. FAM and
-fstrict-flex-arrays.

This does not impact __builtin_object_size interactions with FAM.

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

AArch64LoadStoreOptimizer has a bunch of different guards to avoid
corrupting Windows SEH prologues/epilogues, but apparently we missed the
case of merging two instructions where the first instruction isn't part
of the epilogue, but the second instruction is.

Fixes issue discovered at https://reviews.llvm.org/D130049#3704064

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

When a binary is missing section headers or symbols, objdump can't
provide as good of a disassembly. This change makes objdump try to fetch
a better verion of the binary by its build ID.

Reviewed By: jhenderson

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

a test generates.  The green dragon bot compiler is treating this
warning as an error for some reason, hopefully this will calm its
worries.

Adds a fix to the diagnostic of replacing the `= default` to `= delete`

Reviewed By: aaron.ballman

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

When -fmodule-file-home-is-cwd and the path to the PCM is relative, we
shouldn't assume that the path to the PCM is relative to the modulemap
that produced it. To respect the option -fmodule-file-home-is-cwd, we
should assume the path is relative to the current working directory.

Reviewed By: rmaz

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

Add support for auto-detecting or specifying dSYM files/directories to
allow interleaving source with disassembly.

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

Patch by Jim Radford.

Reviewed By: cota

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

Set CLANG_NO_DEFAULT_CONFIG=1 for clang-tools-extra tests to prevent
the system configuration files for clang from affecting the test
results.

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

Reviewed By: cota

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

These tests have begun failing starting with commit
`69a64174`, which
added a new `import` to `ASTNodeImporter::VisitTypedefType`.
This trips an assertion in following way:
1. When creating a persistent variable for the result we call `CopyType`
   (in `DeportType`) under a `CompleteTagDeclsScope` (which is supposed to complete all
   decls newly imported in the `CopyType` call).
2. During `CopyType` we call `ASTNodeImporter::VisitTypedefType`
3. This now has a second import call on the desugared type
4. In `ASTImporterDelegate::ImportImpl` we will now try to import a decl
   that we originally got from the `std` module (which means it has no valid origin).
   But since we’re doing this under a CompleteTagDeclsScope, the
   `NewDeclListener::NewDeclImported` adds the decl to the list of decls to
   complete after the `CopyType` call. But this list shouldn’t contain decls
   with invalid origins because we assert this in `~CompleteTagDeclsScope`, which
   is where the tests crash.

We suspect that we previously didn’t see this assert trigger because by the time
we create the result variable we are using an AST whose decls all have
a valid debug-info origin (constructed with the help of the std module).
So we never expected decls from modules to be imported under
`CompleteTagDeclsScope` without a m_sema available (which is the case by
the time we get to `DeportType`). Since there is no `m_sema` available,
`CxxModuleHandler::Import` trivially returns and the decls don’t get added
to the `m_decls_to_ignore` list and count as "newly imported decls".

Skip this test for now until we have a fix or the origin tracking gets
refactored (see https://reviews.llvm.org/D101950).

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

This code adds initial support for generating the HLSL resources
metadata entries. It has a lot of `FIXMEs` laying around because there
is a lot more work to do here, but this lays a solid groundwork and can
accurately handle some trivial cases.

I've filed a swath of issues covering the deficiencies here and left the
issues in comments so that we can easily follow them.

One big change to make sooner rather than later is to move some of this
code into a new libLLVMFrontendHLSL so that we can share it with the
Clang CodeGen layer.

Reviewed By: python3kgae

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

 requires-expression

As reported: https://github.com/llvm/llvm-project/issues/57487

We properly treated a failed instantiation of a concept as a
unsatisified constraint, however, we need to do this at the 'requires
clause' level as well.  This ensures that the parameters on a requires
clause that fail instantiation will cause a satisfaction failure.

This patch implements this by running requires parameter clause
instantiation under a SFINAE trap, then stores any such failure as a
requirement failure, so it can be diagnosed later.

[clang][driver][darwin] Ensure that the SDK version passed to -platform_version has a minor version number 0

The linker requires at least a "major.minor" for the SDK version, so it will fail when we don't have
a minor version in the case we don't actually have an SDK info.

This bug was introduced with D134966.

The output is similar to objdump --no-addresses since binutils 2.35.

Depends on D135039
Close #58088

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

It seems to make sense to omit offsets when --no-leading-addr is specified. The output is now closer
to objdump -dr --no-addresses (non-wide output).

Reviewed By: nickdesaulniers

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

This restores the fix from D134925 to make MSVC and clang happy.

Reviewed By: stella.stamenova

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

This adds support for the new code points in the Extended Grapheme
Cluster algorithm. The algorithm itself has remained unchanged.

The width estimation still follows the rules of the Standard.
@cor3ntin filed
  LWG3780 format's width estimation is too approximate and not forward compatible
to improve the estimate.

Reviewed By: ldionne, #libc

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

This is a split of D134250.

Supports for parsing and dumping the LC_DATA_IN_CODE contents (as binary
data).

This allows more complete testing of llvm-objdump in D133974.

Reviewed By: Higuoxing

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

There are few changes mixed in here.

-Try to reuse the destination register from ADDI instead of always
creating a virtual register. This way we lean on the register
scavenger in fewer case.
-Explicitly reuse the primary virtual register when possible. There's
still a case where both getVLENFactoredAmount and handling large
fixed offsets can both create a secondary virtual register.
-Combine similar BuildMI calls by manipulating the Register variables.

There are still a couple early outs for ADDI, but overall I tried to
arrange the code into steps.

Reviewed By: reames

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

The old code took two different paths based on whether there is
a scalable offset, but these two paths had some code in common.

The main difference between the two code paths was whether we needed
to create a GPR or not for the ADDI that gets created for RVVSpill.
If we had a scalable offset, the same GPR was used as the destination
for adding the scalable offset and the ADDI. To manage this, we now
cache the scratch register and reuse it if it has already been created.

This is a pre-patch for D135009.

Reviewed By: reames, frasercrmck

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

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

The `dumpExportEntry` was dumping everything using signed LEB128, but
the format seems to use unsigned LEB128. This can be cross-checked with
the implementation in MachOObjectFile.cpp, the implementation in LLD's
ExportTrie.cpp, and the implementation in macho2yaml.cpp, which all use
ULEB128 functions..

The difference is only apparent when encoding some values with specific
bit patterns (bit active in the 7th, 14th, ... bits of the binary). The
encoding was not always creating problems in the resulting binaries
because if the extra byte was part of the padding, the result of
decoding it as ULEB128 is the same as decoding as SLEB128, however, the
code of MachOObjectFile.cpp (used by llvm-objdump) checks the buffer
decoding position against the reported length, which triggered an error.

Modified a test that used an address with this pattern (0x3FA0, the 14th
bit is active), to show that a round trip still produces the same
results, and added a check using llvm-objdump to use their extra checks
to verify this implementation.

Reviewed By: pete

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

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