Implements: P2819R2 <https://wg21.link/P2819R2>
- https://eel.is/c++draft/utilities#concept:tuple-like
- https://eel.is/c++draft/complex.syn
- https://eel.is/c++draft/complex.tuple



---------

Co-authored-by: Zingam <zingam@outlook.com>

A CXXConstructExpr may refer to an immediate constructor, in which case
it should be substituted in the
enclosing default init expression.

Fixes #82154

Updates:

- The previous patch changed the default behavior to not load dwos in
`DWARFUnit`
~~`SymbolFileDWARFDwo *GetDwoSymbolFile(bool load_all_debug_info =
false);`~~
`SymbolFileDWARFDwo *GetDwoSymbolFile(bool load_all_debug_info = true);`
- This broke some lldb-shell tests (see
https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/16273/)
- TestDebugInfoSize.py
- with symbol on-demand, by default statistics dump only reports
skeleton debug info size
- `statistics dump -f` will load all dwos. debug info = skeleton debug
info + all dwo debug info

Currently running `statistics dump` will trigger lldb to load debug info
that's not yet loaded (eg. dwo files). Resulted in a delay in the
command return, which, can be interrupting.

This patch also added a new option `--load-all-debug-info` asking
statistics to dump all possible debug info, which will force loading all
debug info available if not yet loaded.

Following up on the review comment in
https://github.com/llvm/llvm-project/pull/79949#discussion_r1482071745

Today, if any instruction uses EncodingInfos/EncodingByHwMode to
override the default encoding, the opcode field of the decoder table is
generated incorrectly. This causes failed disassemblies and other
problems.

Specifically, the main correctness issue is that the EncodingID is
inadvertently stored in the table rather than the actual opcode. This is
caused by having set up the IndexOfInstruction map incorrectly during
the loop to populate NumberedEncodings-- which is then propagated around
when OpcMap is set up with a bad EncodingIDAndOpcode.

Instead, do away with IndexOfInstruction altogether and use opcode value
queried from CodeGenTarget::getInstrIntValue to set up OpcMap. This
itself exposed another problem where emitTable was using the decoded
opcode to index into NumberedEncodings. Instead pass in the
EncodingIDAndOpcode vector, and create the reverse mapping from Opcode
to EncodingID, which is then used to index NumberedEncodings.

This problem is not currently exposed upstream since no in-tree targets
yet use the per-HwMode feature. It does show up in at least two
downstream targets.

[sanitizer][fuchsia] Fix fuchsia buildbot failure after 64790064 (#82202)

In https://github.com/llvm/llvm-project/pull/77488, a param `raw_report`
is added for function `UnmapOrDie()`.
But missing the corresponding change for fuchsia, causes the buildbot
failure, see https://lab.llvm.org/buildbot/#/builders/98/builds/33593.
This patch should fix the fuchsia buildbot failure.

Use journaling streams introduced in #81524 for LinuxKernelRewriter.

- Add a param `raw_report` which defaults to false for function
`UnmapOrDie()` like we do for `MmapOrDie()`
- Add a template param `raw_report` which defaults to false for class
`InternalMmapVectorNoCtor`. `raw_report` will be passed to `MmapOrDie()`
and `UnmapOrDie()` when they are called in class
`InternalMmapVectorNoCtor` member functions.
- Use `InternalMmapVectorNoCtor<char, true>` for `error_message_buffer`
and reallocate if needed.

P9 has vxform `Vector Extract Element Instructions` like `vextuwrx` and
P10 has vxform `Vector Insert Element instructions` like `vinsd`. Update
the instruction cost reflecting these instructions.

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

https://github.com/llvm/llvm-project/commit/1d27669e8ad07f8f2 add
support for fold 512-bit concat(blendi(x,y,c0),blendi(z,w,c1)) to
AVX512BW mask select.
But when the type of subvector is v16i16, we need to generate repeated
mask to make the result correct.
The subnode looks like t87: v16i16 = X86ISD::BLENDI t132, t58,
TargetConstant:i8<-86>.

Static calls are calls that are getting patched during runtime. Hence,
for every such call the kernel runtime needs the location of the call or
jmp instruction that will be patched. Instruction locations together
with a corresponding key are stored in the static call site table. As
BOLT rewrites these instructions it needs to update the table.

Fix an issue that produces a wrong coverage mapping when using binary
conditional operators as show in the example below.

Before this patch:

    1|      1|int binary_cond(int x) {
    2|      1|  x = x ?: 4;
    3|      1|  int y = 0;
    4|      0|  return x;       <-- Not covered
    5|      1|}

After this patch:

    1|      1|int binary_cond(int x) {
    2|      1|  x = x ?: 4;
    3|      1|  int y = 0;
    4|      1|  return x;       <-- Covered
    5|      1|}

Fixes #56021.

VPInstruction doesn't rely on the underlying instruction any longer for
codegen, remove the unneeded setUnderlyingInstr.

See the attached test case.

This fixes two issues.

The return value
----------------

Based on the wording

[istream.unformatted]/37
Effects: Behaves as an unformatted input function (as described above),
  except that it does not count the number of characters extracted and
  does not affect the value returned by subsequent calls to gcount().
  After constructing a sentry object, if rdbuf() is a null pointer,
  returns -1.

[istream.unformatted]/1
... It then creates an object of class sentry with the default argument
noskipws (second) argument true. If the sentry object returns true, when
converted to a value of type bool, the function endeavors to obtain the
  requested input. ...

It could be argued the current behaviour is correct, however
constructing a istream rdbuf() == nullptr creates a sentry that returns
false; its state is always bad in this case.

As mentioned in the bug report, after this change the 3 major
implementations behave the same.

The setting of the state
------------------------

When pubsync returned -1 it updated the local __state variable and
returned. This early return caused the state up the istream not to be
updated to the new state.

Fixes: https://github.com/llvm/llvm-project/issues/51497
Fixes: https://github.com/llvm/llvm-project/issues/51499



---------

Co-authored-by: Louis Dionne <ldionne.2@gmail.com>

This mirrors the existing pattern for pushing unpack down through
padding, restricting to cases where the padded dimensions aren't tiled
by the pack.

Additionally reformats the propagation test to make it easier to read.

fixes #81766

RT must be the type of the RHS, otherwise this later fails when
we set the RHS value to the temporary variable.

EnumArgument may be a string or an identifier. If it is a string, it
should be parsed as unevaluated string literal. Add IsString flag to
EnumArgument so that the parser can choose the correct parsing method.

Target-specific attributes that share spelling may have different
attribute "prototypes". For example, ARM's version of "interrupt"
attribute accepts a string enum, while MSP430's version accepts an
unsigned integer. Adjust ClangAttrEmitter so that the generated
`attributeStringLiteralListArg` returns the correct mask depending on
target triple.

It is worth noting that even after this change some string arguments are
still parsed as identifiers or, worse, as expressions. This is because
of some special logic in `ParseAttributeArgsCommon`. Fixing it is out of
scope of this patch.

- Fixed issue with invalid code being generated when static_cast is put
into fix, and no space were added before it.
- Fixed issue with duplicate parentheses being added when double
implicit cast is used.

Closes #71848

`MCRegister` is preferred over `unsigned` nowadays.

This patch aligns the shift Ops in `arith` with respective LLVM instructions.
Specifically, shifting by an amount equal to the bitwidth of the operand
is now defined to return poison.

Relevant discussion:
https://discourse.llvm.org/t/some-question-on-the-semantics-of-the-arith-dialect/74861/10
Relevant issue: https://github.com/llvm/llvm-project/issues/80960

Extends the `omp.parallel` op by adding a `private` clause to model
[first]private variables. This uses the `omp.private` op to map
privatized variables to their corresponding privatizers.

Example `omp.private` op with `private` variable:
```
omp.parallel private(@x.privatizer %arg0 -> %arg1 : !llvm.ptr) {
  ^bb0(%arg1: !llvm.ptr):
    // ... use %arg1 ...
    omp.terminator
}
```

Whether the variable is private or firstprivate is determined by the
attributes of the corresponding `omp.private` op.

Close https://github.com/llvm/llvm-project/issues/80949

Previously, I thought the always-inline function can be an exception to
enable optimizations as much as possible. However, it looks like it
breaks the ABI requirement we discussed later. So it looks better to not
import non-inline function bodies at all even if the function bodies are
marked as always_inline.

It doesn't produce regressions in some degree since the always_inline
still works in the same TU.

Progress towards #77627

---------

Co-authored-by: SahilPatidar <patidarsahil@2001gmail.com>
Co-authored-by: Lei Zhang <antiagainst@gmail.com>

This reverts commit 21ddd7ff because it
breaks a bunch of tests:

https://lab.llvm.org/buildbot/#/builders/68/builds/69018
https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/16273

The unit tests only test the Python objects and don't actually use
anything from the LLDB module. That means that all the additional
complexity in ScriptInterpreterPythonImpl::Initialize is overkill.

By doing the initialization by hand, we avoid the annoying
ModuleNotFoundError.

  Traceback (most recent call last):
    File "<string>", line 1, in <module>
  ModuleNotFoundError: No module named 'lldb'

The error is the result of us stubbing out the SWIG (specifically
`PyInit__lldb`) because we cannot link against libLLDB from the unit
tests.

The downside of doing the initialization manually is that we do lose a
bit of test coverage. For example, issue #70453 also manifested itself
in the unit tests.

There were a couple things in the comments of BenchmarkRunner.cpp (and
maybe other files, I can't really remember) that were bugging me. This
patch fixes a couple of minor issues specifically in BenchmarkRunner
like typos and makes a couple instances more clear.

The Python documentation [1] says that `PyImport_AppendInittab` should
be called before `Py_Initialize()`. Starting with Python 3.12, this is
enforced with a fatal error:

  Fatal Python error: PyImport_AppendInittab: PyImport_AppendInittab()
  may not be called after Py_Initialize()

This commit ensures we only modify the table of built-in modules if
Python hasn't been initialized. For Python embedded in LLDB, that means
this happen exactly once, before the first call to `Py_Initialize`,
which becomes a NO-OP after. However, when lldb is imported in an
existing Python interpreter, Python will have already been initialized,
but by definition, the lldb module will already have been loaded, so
it's safe to skip adding it (again).

This fixes #70453.

[1] https://docs.python.org/3.12/c-api/import.html#c.PyImport_AppendInittab

It seems the `Traits.md` file was turned into `Traits/_index.md` in
https://reviews.llvm.org/D153291, causing links to `Traits.md` to no
longer work (instead, `Traits` needs to be used).