Most of the cases were where a C++ file was being compiled with the C substitution.
There were a few cases of the opposite though.

LLDB seems to be the only real culprit in the LLVM codebase for these mismatches.
Rest of the LLVM presumably sticks at least language-specific options in the common substitutions
making the mistakes immediately apparent.

I found these by using Clang frontend configuration files containing language-specific options for
both C and C++ (e.g. `-std=c2y` and `-std=c++26`).

LLDB breakpoint conditions take an expression that's evaluated using the
language of the code where the breakpoint is located. Users have asked
to have an option to tell it to evaluate the expression in a specific
language.

This is feature is especially helpful for Swift, for example for a
condition based on the value in memory at an offset from a register.
Such a condition is pretty difficult to write in Swift, but easy in C.

This PR adds a new argument (-Y) to specify the language of the
condition expression. We can't reuse the current -L option, since you
might want to break on only Swift symbols, but run a C expression there
as per the example above.

rdar://146119507

Fixes [#68035](https://github.com/llvm/llvm-project/issues/68035), where
an inconsistency in the order of "Process launched" and "Process
stopped" messages occurs during `process launch`.

The fix involves adjusting the message output sequence in
`CommandObjectProcessLaunch::DoExecute` within
`source/Commands/CommandObjectProcess.cpp`. This ensures "Process
launched" consistently precedes "Process stopped" when executing
commands with the '-o' flag, i.e., non-interactive mode.

Upon implementing this change, two tests failed:
`lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test` and
`lldb/test/Shell/Breakpoint/jit-loader_rtdyld_elf.test`. These failures
were expected as they relied on the previous, now-corrected message
order. Updating these tests to align with the new message sequence is
part of this PR's scope.

lldb/test/Shell/Breakpoint/breakpoint-command.test adds a python
command, to be executed when a breakpoint hits, that writes out a
number. It then runs, hits the breakpoint and checks that the number is
present exactly once.

The problem is that on some systems the test can be run in a filepath
that happens to contain the number (e.g. auto-generated directory
names). The number is then detected multiple times and the test fails.

This patch fixes the issue by using a string instead, particularly a
string with spaces, which is very unlikely to be auto-generated by any
system.

My local build is with -DLLVM_ENABLE_PROJECTS=lldb, but I don't compile
with -DLLDB_ENABLE_PYTHON=True or -DLLDB_ENABLE_LUA=True. This results
in there being no script interpreter.

The test lldb/test/Shell/Breakpoint/breakpoint-command.test has an
implicit dependency on a script interpreter being available.

This patch makes that dependency clear. If you have a script
interpreter, the test gets run, otherwise it gets skipped. This means
that folks (like me) who naively use -DLLVM_ENABLE_PROJECTS=lldb can
continue to run check-all without breakages.

Reviewed By: JDevlieghere

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

Fix failling jit-loader tests with BUILD_SHARED_LIBS as discussed in https://github.com/llvm/llvm-project/issues/56085

Reviewed By: mgorny

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

The functionality is fine (we don't run the breakpoint command twice), but this test forgot to call `FileCheck` and isn't checking the same value isn't there twice..

Fixes #19721
Fixes #18440
Partially fixes bug #47660
Fixes #47761
Fixes #47763

Sponsored by: The FreeBSD Foundation

Currently, ppc64le and ppc64 (defaulting to big endian) have the same
descriptor, thus the linear scan always return ppc64le. Handle that through
subtype.

This is a recommit of f114f009486816ed4b3bf984f0fbbb8fc80914f6 with a new test
setup that doesn't involves (unsupported) corefiles.

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

This test is making the Windows bot unhappy. Unfortunately the output
doesn't tell me much about what exactly is wrong.