This removes some uses of the deprecated `FileEntry::getName()`.

Fix compile errors in example provided in
documentation.

Fixes: #65118

This allows us to produce better error messages for types that were only
forward-declared, but where a full definition was expected.

The first user will be https://reviews.llvm.org/D159013; this change is
sent to review separately to reduce the scope of the other patch.

This commit replaces some calls to the deprecated `FileEntry::getName()` with `FileEntryRef::getName()` by swapping current usages of `SourceManager::getFileEntryForID()` with `SourceManager::getFileEntryRefForID()`. This lowers the number of usages of the deprecated `FileEntry::getName()` from 95 to 50.

Use the same arguments as other builds. This gives better output to
validate what the CI did.

Reviewed By: #libc, ldionne

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

`clang` currently links `libgcc_s` unconditionally on Solaris, which is
unnecessary.

This patch wraps it in `-z ignore`/`-z record` instead.

Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.

This function has the same semantics as
`std::shared_ptr<T>::use_count()`, and enables implementing
copy-on-write semantics.

Reviewed By: #libc, ldionne

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

Issue Details:
When building up line information for CodeView debug info, LLVM attempts to gather the "range" of instructions within a function as these are printed together in a single record. If there is an inlined function, then those lines are attributed to the original function to enable generating `S_INLINESITE` records. However, this thus requires there to be instructions from the inlining function after the inlined function otherwise the instruction range would not include the inlined function.

Fix Details:
Include any inlined functions when finding the extent of a function in `getFunctionLineEntries`

Reviewed By: rnk

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

Hopefully this fixes the expensive checks build.

The function assumes that `__kmp_gtid_get_specific` always returns a valid gtid.
That is not always true, because when creating the key for thread-specific data,
a destructor is assigned. The dtor will be called at thread exit. However, before
the dtor is called, the thread-specific data will be reset to NULL first
(https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_key_create.html):

> At thread exit, if a key value has a non-NULL destructor pointer, and the thread
> has a non-NULL value associated with that key, the value of the key is set to NULL.

This will lead to that `__kmp_gtid_get_specific` returns `KMP_GTID_DNE`.

Reviewed By: jdoerfert

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

The outlined function is typically invoked by using
`__kmp_invoke_microtask`,
which is written in asm. D138495 introduces a new interface function for
parallel
region for OpenMPIRBuilder, where the outlined function is called via
the function
pointer. For some reason, it works perfectly well on x86 and x86-64
system, but
doesn't work on Apple Silicon. The 3rd argument in the callee is always
`nullptr`, even
if it is not in caller. It appears `x2` always contains `0x0`. This
patch adopts
the typical method to invoke the function pointer. It works on my M2
Ultra Mac.

Fix #63194.

Reviewed By: vitalybuka

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

Fixed a compile  error on  use of deleted function ¡®{anonymous}::MemberData::MemberData(const {anonymous}::MemberData&)

Summary:

There is compile error on https://lab.llvm.org/buildbot/#/builders/264/builds/1147/steps/5/logs/stdio
when commit in https://reviews.llvm.org/D144872

Make the DAGCombine helper global so we can more easily reuse it.

This test still fails since RuntimeDyldChecker needs a few fixes before it works with Thumb. We can remove the XFAIL once the patch in D158280 landed.

Summary:

if the member file is XCOFF object file and has auxiliary header, the content of the member file need to be aligned at the
MAX(maximum alignment of .text , maximum alignment of .data). The "maximum alignment of .text" and "maximum alignment of .data" are two
field of auxiliary header of XCOFF object file.

Reviewers: James Henderson, Stephen Peckham
Differential Revision: https://reviews.llvm.org/D144872

VPWidenRecipe only needs the opcode to widen, all other information
(flags, debug loc and operands) is already modeled directly via the
recipe.

This removes the remaining uses of the underlying instruction from
VPWidenRecipe::execute.

We have docs about how to use lldb on other programs, this tells you how
to use lldb on ldlb and lldb-server.

Lacking any Mac experience I've not included any debugserver information
apart from stating it will be similar but not the same.

I plan for this page to include sections on debugging tests and other
things but this initial commit is purely about the two main binaries
involved.

The optnone tests, following the removal of the Dexter builder in a
prior patch (45a40c16), are experiencing intermittent failures. This
patch marks them unsupported to be fixed in a new commit, rather than
reverting the Dexter patch.

This is a followup of D157625. Using the name clang-modules-build makes
it clear this is regarding the clang modules and not the C++23 std or
std.compat module.

Reviewed By: #libc, ldionne

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

In patch D157792, the calls to SYS_llseek/SYS_llseek for 32-bit systems
were fixed in lseek.cpp but there was another implementation in file.cpp
that was missed.

To reduce the code duplication, this patch unifies both call sites to
use a new lseekimpl function.

Reviewed By: sivachandra

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

Currently we hoist conditions from widenable branch which are joined to
the widenable_condition by And operation. E.g if we have
br(WC && (c1 && c2)) we will operate with (c1 && c2) unsplitted.

This patch adds more flexibility to that mechanism by supporting work
with the list of checks parsed from the widenable branch.

On that stage patch doesn't change the logic of checks hoisting. In the
example above we will either hoist both checks [c1, c2] or none of them.
But in the future we would improve that logic analyzing each check
separately.

Reviewed By: anna

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

Implement LWG3938 (Cannot use std::expected monadic ops with move-only error_type)
https://wg21.link/LWG3938

Reviewed By: #libc, ldionne

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

/Users/jiefu/llvm-project/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp:959:3: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default]
  default:
  ^
1 error generated.

This patch makes a further attempt to fix the tests broken by the
previous revision by ensuring that the command line for the modified
Dexter tests use -std=gnu++11, in keeping with the old build script.

This reverts commit 5647f290.

[llvm-cov] - Output better error message when the error kind is `coveragemap_error::malforme`. (#65264)

The current llvm-cov error message for kind `coveragemap_error::malforme`, just gives the issue kind without any reason for what caused the issue. This patch is aimed at improving the llvm-cov error message to help identify what caused the issue.

Reviewed By: MaskRay
Close: https://github.com/llvm/llvm-project/pull/65264

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

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

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

This should fix CI issues introduced by 065dc485 where the std.cppm
module won't build in C++20 mode because views::chunk_by was added in
C++23 but wasn't marked as such in ranges.inc.

At the moment,

  - Provide only `profile`
  - Will invoke error unless the platform is linux

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

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

Putting preferred header signal above completeness implied we would
uprank forward declarations above complete ones in certain cases.

This can be desired in cases where:
- Complete definition is private. But this case is already governed by
  publicness signal.
- The library indeed intends to provide a forward declaring interface, like
  iosfwd vs ostream.

In all other cases, upranking is undesired as it means we've picked up prefered
headerness signal by mistake from an unrelated declaration to the library.

This change regresses the behavior for libraries that intentionally provide a
forward declaring interface. But that wasn't something we intended to support
explicitly, it was working incidentally when the forward declaring header had a
similar name to the symbol. Moreover, include-cleaner deliberately discourages
forward-declarations, so not working in this case is also more aligned with rest
of the components.

Differential Revision: h...