This fixes a crash where `path::parent_path` causes an invalid
access on a string upon receiving a path that consists of a single colon.

On Windows machine, with runtime checks enabled build, upon `clang -I: test.cc` produces:
```
Assertion failed: Index < Length && "Invalid index!", file llvm\include\llvm/ADT/StringRef.h, line 232
...
 #6 0x00007ff7816201eb `anonymous namespace'::parent_path_end llvm\lib\Support\Path.cpp:144:0
 #7 0x00007ff781620135 llvm::sys::path::parent_path(class llvm::StringRef, enum llvm::sys::path::Style) llvm\lib\Support\Path.cpp:470:0
```

Ideally, we can look for the last colon starting from the last
character, but we can instead start from second to last, and handle
empty paths by abusing `0 - 1 == npos`.

We implement two functions that are needed to compute the constant term
of a GF.
One finds a vector not orthogonal to all the non-null vectors in a given
set.
One computes the coefficient of any term in an arbitrary rational
function (quotient of two polynomials).

This tracks our progress implementing the OpenSSF Best Practices for
LLVM.

From #75735, Zvfh implies Zvfhmin.

This is a followup of #76983 and adds the libc++ data formatters for
- weekday,
- weekday_indexed,
- weekday_last,
- month_weekday,
- month_weekday_last,
- year_month,
- year_month_day_last
- year_month_weekday, and
- year_month_weekday_last.

This tries to fix a bug by resolving a few FIXMEs. The bug is that
`EraseInstAction` is emitted after emitting the _first_ `BuildMIAction`,
which is too early because the erased instruction may still be used by
subsequent `BuildMIAction`s (in particular, by `CopyRenderer`).

An example of the bug (from `match-table-operand-types.td`):
```
def InstTest0 : GICombineRule<
  (defs root:$a),
  (match  (G_MUL i32:$x, i32:$b, i32:$c),
          (G_MUL $a, i32:$b, i32:$x)),
  (apply  (G_ADD i64:$tmp, $b, i32:$c),
          (G_ADD i8:$a, $b, i64:$tmp))>;

GIR_EraseFromParent, /*InsnID*/0,
GIR_BuildMI, /*InsnID*/1, /*Opcode*/GIMT_Encode2(TargetOpcode::G_ADD),
GIR_Copy, /*NewInsnID*/1, /*OldInsnID*/0, /*OpIdx*/0, // a
GIR_Copy, /*NewInsnID*/1, /*OldInsnID*/0, /*OpIdx*/1, // b
GIR_AddSimpleTempRegister, /*InsnID*/1, /*TempRegID*/0,
```

Here, the root instruction is destroyed before copying its operands ('a'
and 'b') to the new instruction.

The solution is to emit `EraseInstAction` for the root instruction as
the last action in the emission pipeline.

This fixes a long-standing FIXME item.

Unfortunately it changes the diagnostic output of the tests added in
`cxx23.cpp`, but they were wrong before and are wrong after, so no big
deal.

Since the example (llvm/examples/Kaleidoscope/Chapter2/toy.cpp) is
self-contained there is no need to use LLVM.

The linker name is different if the `lld` project is enabled
`-DLLVM_ENABLE_PROJECTS="...;lld"`.

---------

Co-authored-by: Leandro Lupori <leandro.lupori@gmail.com>

`PassBuilder` would be a better place to parse MIR pipeline. We can
reuse the code to support parsing pass with parameters and targets can
reuse `registerPassBuilderCallbacks` to register the target specific
passes. `PassBuilder` also has ability to check whether a Pass is a
machine pass.

Forward fix for https://github.com/llvm/llvm-project/pull/75256

The process for MmapAlignedOrDieOnFatalError involves trimming the start
and end of a mapping to ensure it's aligned correctly. This invloves
calling zx_vmar_map again but overwriting a part of the original vmar
which involves a call to zx_object_get_info(ZX_INFO_VMAR). After
https://github.com/llvm/llvm-project/pull/75256, we unconditionally
called this on gSanitizerHeapVmar but this can lead to a
ZX_ERR_INVALID_ARGS if the prior mapping was on the root vmar.

This can be fixed by also returning the vmar we did the last mapping to
and using that for followup operations that specifically involve the
same vmar. This way we don't have to try each syscall for both vmars.

This lets the backend read the `tune-cpu` directive that is emitted by the frontend.

No changes are needed for clang as it is already emits it.

The FreeMemory function only accepts a void pointer, but it was being
called with a const char pointer, resulting in a type-casting issue.
To address this, the const was removed, use char * instead.

XRay used to struggle reading large log files. It turned out the
bottleneck was primarily caused by the reallocation happens when
appending log entries into a std::vector.
This patch reserves the memory space ahead-of-time since the number of
entries is known for most cases. Making llvm-xray runs 1.8 times faster
and uses 1.4 times less physical memory when reading large (~2.6GB) log
files.

Placing the class id at offset 0 should make `isa` and `dyn_cast` faster
by eliminating the field offset (previously 0x10) from the memory
operand, saving encoding space on x86, and, in theory, an add micro-op.
You can see the load encodes one byte smaller here:
https://godbolt.org/z/Whvz4can9

The compile time tracker shows some modestly positive results in the
on the `cycle` metric and in the final clang binary size metric:
https://llvm-compile-time-tracker.com/compare.php?from=33b54f01fe32030ff60d661a7a951e33360f82ee&to=2530347a57401744293c54f92f9781fbdae3d8c2&stat=cycles
Clicking through to the per-library size breakdown shows that
instcombine size reduces by 0.68%, which is meaningful, and I believe
instcombine is known to be a hotspot.

It is, however, potentially noise. I still think we should do this,
because notionally, the class id really acts as the vptr of the Value,
and conventionally the vptr is always at offset 0.

Some builds don't enable the x86_64 target, so we sometimes don't see register names in DWARF output.

These two constructs were both handled in `genOMP` for loop constructs.
There is some shared code between the two, but there are also enough
differences to separate these two cases into individual functions.

The shared code converting loop bounds and steps has been extracted
into a separate function.

Recursive lowering [1/5]

The updated picolibc version has "isblank" function with external
linkage. This is required for C++ modules support.

This should solve all the problems reported in #76980, but
we'll wait to validate this with the modules build without
closing that issue.

This adds API tests for the `target.max-string-summary-length`, which
was recently fixed in https://github.com/llvm/llvm-project/pull/72233

This makes it consistent with how other linalg operations represent
indexing maps.

When generating a `display_value` for a variable the current approach
calls `SBValue::GetValue()` and `SBValue::GetSummary()` to generate a
`display_value` for the `SBValue`. However, there are cases where both
of these return an empty string and the fallback is to print a pointer
and type name instead (e.g. `FooBarType @ 0x00321`).

For swift types, lldb includes a langauge runtime plugin that can
generate a description of the object but this is only used with
`SBValue::GetDescription()`.

For example:
```
$ lldb swift-binary
... stop at breakpoint ...
lldb> script
>>> event = lldb.frame.GetValueForVariablePath("event")
>>> print("Value", event.GetValue())
Value None
>>> print("Summary", event.GetSummary())
Summary None
>>> print("Description", event) # __str__ calls SBValue::GetDescription()
Description (main.Event) event = (name = "Greetings", time = 2024-01-04 23:38:06 UTC)
```

With this change, if GetValue and GetSummary return empty then we try
`SBValue::GetDescription()` as a fallback before using the previous
logic of printing `<type> @ <addr>`.

BreakpointIDList does not need to know about CommandReturnObject.
BreakpointIDList::FindAndReplaceIDRanges is the last place that uses it
in BreakpointIDList.

Instead of passing in a CommandReturnObject, it now returns an
llvm::Error. The callsite uses the Error to populate the
CommandReturnObject as needed.

Allow the dumping of .dwo files contents to show up when dumping an executable with split DWARF. (#66726)

Allow the dumping of .dwo files contents to show up when dumping an
executable with split DWARF.

Currently if you run llvm-dwarfdump on a binary that has skeleton
compile units, you only see the skeleton compile units. Since the main
binary has the linked addresses it would be nice to be able to dump
DWARF from the .dwo files and how the resolved addresses instead of
showing the address index and "<unresolved>" in the output. This patch
adds an option that can be specified to dump the non skeleton DIEs named
--dwo.

Added the ability to use the following options with split dwarf as well:
  --name <name>
  --lookup <addr>
  --debug-info <die-offset>

When I added the MD5 checksum I was on the fence between storing it in
FileSpec or creating a new SupportFile abstraction. The latter was
deemed overkill for just the MD5 hashes, but support for inline sources
in the DWARF 5 line table tipped the scales. This patch moves the MD5
checksum into the new SupportFile class.

Reduces BAT section size:
- large binary: to 12283500 bytes (0.32x original size),
- medium binary: to 1616020 bytes (0.27x original size),
- small binary: to 404 bytes (0.28x original size).

Test Plan: Updated bolt/test/X86/bolt-address-translation.test

Reverts llvm/llvm-project#77851