Fix linkage of `build_name`; it is not supposed to have external linkage.

Currently in Core dumps, the entire pthread is copied, including the
unused space beyond the stack pointer. This causes large amounts of core
dump inflation when the number of threads is high, but the stack usage
is low. Such as when an application is using a thread pool.

This change will optimize for these situations in addition to generally
improving the core dump performance for all of lldb.

Summary:
A runtime library should not have global constructors. Everything is now
expected to go through the init methods. This patch ensures that global
constructors will not accidentally be introduced.

We currently don't support passing files and don't need frontend involvement either.

Split of https://github.com/llvm/llvm-project/pull/90835
Adds support for `TransferReadOfExtractSliceOpFolder` when the
`TransferReadOp` is inside a `MaskOp`.

https://github.com/llvm/llvm-project/pull/71328 refactored
`llvm-profdata.cpp` to use subcommands (which is super nice), but left
many unused `argv` variables. This opts to use `ProgName` where
necessary, and removes `argv` otherwise.

This patch adds comments for writeMemProf{V0,V1,V2} in a
version-specific manner.  The mostly repetitive nature of the comments
is somewhat unfortunate but intentional to make it easy to retire
older versions.

Without this patch, the comment just before writeMemProf documents the
Version1 format, which is very confusing.

Summary:
This was written before we had the address space helpers. Using
numerical address spaces is bad so this should be removed.

Summary:
Previously, the R&R support was global state initialized by a global
constructor. This is bad because it prevents us from adequately
constraining the lifetime of the library. Additionally, we want to
minimize the amount of global state floating around.

This patch moves the R&R support into a plugin member like everything
else. This means there will be multiple copies of the R&R implementation
floating around, but this was already the case given the fact that we
currently handle everything with dynamic libraries.

LLVM is built with C++17, where left shift of any negative value is still UB.
Detected with UBSan on the buildbot.

This reverts commit 0647d103.

Added a unittest demonstrating Error -> Expected<T> forwarding.

The code seems easier to read if it's centered on what the user wants rather than combinations of whatever internal variables.

Namely, we specify that `auto` in a lambda parameter is a C++14
extension in the error message, which now reads:

`'auto' not allowed in lambda parameter before C++14`

This does not change the behavior for `decltype(auto)` and `__auto_type`
though.

---------

Co-authored-by: cor3ntin <corentinjabot@gmail.com>

[clang] CTAD alias: Emit a more descriptive diagnostic message when is_deducible  constraint is evaluated to false. (#92389)

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

The dictionary entry `=""` is invalid.

When the argument passed to `ASTContext::getUnconstrainedType` is an
unconstrained `AutoType`, will return the argument unchanged. However,
when called with a constrained `AutoType`, an unconstrained,
non-dependent `AutoType` will be returned even if the argument was
dependent. Consider the following:
```
template<typename T>
concept C = sizeof(T) == sizeof(int);

template<auto N>
struct A;

template<C auto N>
struct A<N>; // error: class template partial specialization is not more specialized than the primary template
```
When comparing the template parameters for equivalence,
`ASTContext::getUnconstrainedType` is used to remove the constraints per
[temp.over.link] p6 sentence 2. For the template
parameter `N` of the class template, it returns a dependent `AutoType`.
For the template parameter `N` of the class template partial
specialization, it returns a non-dependent `AutoType`. We subsequently
compare the adjusted types and find they are not equivalent, thus we
consider the partial specialization to not be more specialized than the
primary template per [temp.func.order] p6.2.2.

This patch changes `ASTContext::getUnconstrainedType` such that the
dependence of a constrained `AutoType` will propagate to the returned
unconstrained `AutoType`. This causes the above example to be correctly
accepted, fixing #77377.

This is valid as long as the sign of the wrap flag doesn't differ from
the sign of the `pred`.

Proofs: https://alive2.llvm.org/ce/z/35NsrR

NB: The online Alive2 hasn't been updated with `trunc nuw/nsw`
support, so the proofs must be reproduced locally.

Closes #87935

`(icmp ule/ult (add nuw X, Y), C)` implies both `(icmp ule/ult X, C)` and
`(icmp ule/ult Y, C)`. We can use this to deduce leading zeros in `X`/`Y`.

`(icmp uge/ugt (sub nuw X, Y), C)` implies `(icmp uge/uge X, C)` . We
can use this to deduce leading ones in `X`.

Proofs: https://alive2.llvm.org/ce/z/sc5k22

Closes #87180

The README.md is what users see when they look for the extension in the
Marketplace [1]. Right now, it's a mix of developer documentation (for
us) and user documentation. This commit moves the developer docs into
`docs` and the lldb website and refocuses the README on using the
extension.

[1] https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.lldb-dap

This patch groups the three Memprof data structures into a struct
named IndexedMemProfData and teaches InstrProfWriter to use it.  This
way, we can pass IndexedMemProfData to writeMemProf and its helpers
instead of individual data structures.

As a follow-up, we can use the new struct in MemProfReader also.  That
in turn allows loadInput in llvm-profdata to move the MemProf data
into the writer context, saving a few seconds for a large MemProf
profile.

These tests are based on dap_server which runs locally. These tests
failed in case of Windows host and Linux target.

## Abstract

This pull request implements LWG3672: `common_iterator::operator->()`
should return by value. The current implementation specifies that this
function should return the underlying pointer by reference (`T*
const&`), but it would be more intuitive to return it by value (`T*`).

## Reference

- [Draft C++ Standard:
[common.iter.access]](https://eel.is/c++draft/common.iter.access)
- [LWG3672](https://cplusplus.github.io/LWG/issue3672)

Use https://github.com/llvm/vscode-lldb instead of the monorepo, for
consistency with the other two extensions (mlir, clangd).

Revert "[Clang][CWG1815] Support lifetime extension of temporary created by aggregate initialization using a default member initializer (#87933)"

This reverts commit 17daa204.

Multiple examples on the PR
https://github.com/llvm/llvm-project/pull/87933

show regressions, so reverting until they can be fixed in the followup.

Summary:
Forgot to remove these when I landed the initial patch, they are no
longer used.

For every variable used under `#pragma omp task` directive
(`DeclRefExpr`) an ImplicitPrivateVariable is created in the AST, if
`private` or `shared` clauses are not present. If the variable has the
property of `non_odr_use_unevaluated` e.g. for statements which use
`sizeof( i )` `i` will have `non_odr_use_unevaluated` . In such cases
CodeGen was asserting by avoiding emitting of LLVM IR for such
variables. To prevent this assertion this checkin avoids adding the
ImplicitPrivateVariable for variables with `non_odr_use_unevaluated`.

---------

Authored-by: Sunil Kuravinakop <kuravina@pe28vega.us.cray.com>

Reland of https://github.com/llvm/llvm-project/pull/91334, which broke
the gcc7 buildbot and was reverted in
https://github.com/llvm/llvm-project/pull/92321.
Work around the failure by being explicit about returning an `Expected`.

cc @joker-eph

I accidentally left out the code to transfer sret attributes to entry
thunks, so values weren't being passed in the right registers, and the
sret pointer wasn't returned in the correct register.

Fixes #90229

Summary:
Currently this is only used for the zero-copy handling. However, this
can easily be moved into `libomptarget` so that we do not need to bother
setting the requires flags in the plugin. The advantage here is that we
no longer need to do this for every device redundently. Additionally,
these requires flags are specifically OpenMP related, so they should
live in `libomptarget`.

[DAG] SimplifyDemandedBits - use ComputeKnownBits instead of getValidShiftAmountConstant to check for constant shift amounts. (#92412)

This allows us to handle cases where the constant has already been type legalized behind a bitcast

Despite calling ComputeKnownBits I'm not seeing any notable change in compile time.

Address comments missed when landing
https://github.com/llvm/llvm-project/pull/85689.

This PR is an implementation for changes proposed in
https://discourse.llvm.org/t/rfc-distinguish-between-data-and-non-data-in-fir-alias-analysis/78759

Test updates were made when the query was on the wrong reference. So, it
is my hope that this will clear ambiguity on the nature of the queries
from here on.
There are also some TODOs that were addressed. 

It also partly implements what
https://github.com/llvm/llvm-project/pull/87723 is attempting to
accomplish. At least, on a point-to-point query between references, the
distinction is made. To apply it to TBAA, would be another PR.

Note that, the changes were minimal in the TBAA code to retain the
current results.

The -Wunsafe-buffer-usage warning should fire on any call to a function
annotated with [[clang::unsafe_buffer_usage]], however it omitted calls
to constructors, since the expression is a CXXConstructExpr which does
not subclass CallExpr. Thus the matcher on callExpr() does not find
these expressions.

Add a new WarningGadget that matches cxxConstructExpr that are calling a
CXXConstructDecl annotated by [[clang::unsafe_buffer_usage]] and fires
the warning. The new UnsafeBufferUsageCtorAttrGadget gadget explicitly
avoids matching against the std::span(ptr, size) constructor because
that is handled by SpanTwoParamConstructorGadget and we never want two
gadgets to match the same thing (and this is guarded by asserts).

The gadgets themselves do not report the warnings, instead each gadget's
Stmt is passed to the UnsafeBufferUsageHandler (implemented by
UnsafeBufferUsageReporter). The Reporter is previously hardcoded that a
CXXConstructExpr statement must be a match for std::span(ptr, size), but
that is no longer the case. We want the Reporter to generate different
warnings (in the -Wunsafe-buffer-usage-in-container subgroup) for the
span contructor. And we will want it to report more warnings for other
std-container-specific gadgets in the future. To handle this we allow
the gadget to control if the warning is general (it calls
handleUnsafeBufferUsage()) or is a std-container-specific warning (it
calls handleUnsafeOperationInContainer()).

Then the WarningGadget grows a virtual method to dispatch to the
appropriate path in the UnsafeBufferUsageHandler. By doing so, we no
longer need getBaseStmt in the Gadget interface. The only use of it for
FixableGadgets was to get the SourceLocation, so we make an explicit
virtual method for that on Gadget. Then the handleUnsafeOperation()
dispatcher can be a virtual method that is only in WarningGadget.

The SpanTwoParamConstructorGadget gadget dispatches to
handleUnsafeOperationInContainer() while the other WarningGadgets all
dispatch to the original handleUnsafeBufferUsage().

Tests are added for annotated constructors, conversion operattors, call
operators, fold expressions, and regular methods.

Issue #80482

Test for this paper were added in https://github.com/llvm/llvm-project/pull/91435