Since the NTTP may need to be cast to the type when rebuilding the name,
check that the type can be rebuilt when determining whether a template
name can be simplified.

We could only do this in limited ways (since we emit the TUs first, we
can't use ref_addr (& we can't use that in Split DWARF either) - so we
had to synthesize declarations into the TUs) and they were ambiguous in
some cases (if the CU type had internal linkage, parsing the TU would
require knowing which CU was referencing the TU to know which type the
declaration was for, which seems not-ideal). So to avoid all that, let's
just not reference types defined in the CU from TUs - instead moving the
TU type into the CU (recursively).

This does increase debug info size (by pulling more things out of type
units, into the compile unit) - about 2% of uncompressed dwp file size
for clang -O0 -g -gsplit-dwarf. (5% .debug_info.dwo section size
increase in the .dwp)

This information isn't preserved in the DWARF description of function
types (though probably should be - it's preserved on the function
declarations/definitions themselves through the DW_AT_noreturn attribute
- but we should move or also include that in the subroutine type itself
too - but for now, with it not being there, the DWARF is lossy and
can't be reconstructed)

Add a test checking that each SIMD intrinsic produces the expected instruction.
Since this test spans both clang and LLVM, place it in a new
intrinsic-header-tests subdirectory of cross-project-tests.

This revives D101684 now that cross-project-tests exists. In practice, the tests
of lowering from wasm_simd128.h to LLVM IR were not as useful as this end-to-end
test.

Updates the version check of gdb in cross-project-tests/lit.cfg.py so that
unexpected version formats do not prevent the new tests from running.

Depends on D121661.

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

This mechanically applies the same changes from D121427 everywhere.

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

This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.

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

Breakpoint deletion in visual studio is currently implemented by
iterating over the breakpoints we want to delete, for each of which we
iterate over the complete set of breakpoints in the debugger instance
until we find the one we wish to delete. Ideally we would resolve this
by directly deleting each breakpoint by some ID rather than searching
through the full breakpoint list for them, but in the absence of such a
feature in VS we can instead invert the loop to improve performance.

This patch changes breakpoint deletion to iterate over the complete list
of breakpoints, deleting breakpoints that match the breakpoints we
expect to delete by checking set membership. This represents a
worst-case improvement from O(nm) to O(n), for 'm' breakpoints being
deleted out of 'n' total. In practise this is almost exactly 'm'-times
faster, as when we delete multiple breakpoints they are typically
adjacent in the full breakpoint list.

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

Since -gmlt doesn't carry any type information necessary to rebuild
template names.

_BitInt(N) only encodes the byte size in DWARF, not the bit size, so
can't be reconstituted.

Dexter saves various files to a new results directory each time it is run
(including when it's run by lit tests) and there isn't a way to opt-out. This
patch reconfigures the behaviour to be opt-in by removing the default
`--results-directory` location. Now results are only saved if
`--results-directory` is specified.

Reviewed By: jmorse

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

Due to the way type units work, this would lead to a declaration in a
type unit of a local type in a CU - which is ambiguous. Rather than
trying to resolve that relative to the CU that references the type unit,
let's just not try to simplify these names.

Longer term this should be fixed by not putting the template
instantiation in a type unit to begin with - since it references an
internal linkage type, it can't legitimately be duplicated/in more than
one translation unit, so skip the type unit overhead. (but the right fix
for that is to move type unit management into a DICompositeType flag
(dropping the "identifier" field is not a perfect solution since it
breaks LLVM IR linking decl/def merging during IR linking))

Lambda names aren't entirely canonical (as demonstrated by the
cross-project-test added here) at the moment (we should fix that for a
bunch of reasons) - even if the template referencing them is
non-simplified, other names referencing /that/ template can't be
simplified either because type units might cause a different template to
be picked up that would conflict with the expected name.

(other than for roundtripping precision, it'd be OK to simplify types
that reference types that reference lambdas - but best be consistent
between the roundtrip/verify mode and the actual simplified template
names mode)

Some configurations of gdb pretty print std::deque and some don't. Make
this test run only on system-darwin (which uses lldb instead), otherwise
it will fail on some non-darwin machines and not others.

And XFAIL debuginfo-tests/llgdb-tests/asan-deque.cpp on !system-darwin.
On non-darwin systems these tests use gdb and this one fails because gdb
doesn't pretty-print std::deque (the elements of the deque are not printed so
the CHECK lines fail).

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

Follow up to D118468 (5257efdc).

When built from source, gdb's version string looks like this:

    GNU gdb (GDB) 9.2
    ...

But for installed versions it looks different. E.g.

    GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
    ...

Use a regex rather than str.parition in the version string parsing in order to
handle this case too.

Tests in the `cross-project-tests/debuginfo-tests/llgdb-tests` directory run
gdb on non-darwin platforms. gdb versions less than 10.1 cannot parse the DWARF
v5 emitted by clang, and DWARF v5 is now the default, so these tests fail on
Linux with gdb versions less than 10.1. This patch lets us XFAIL the tests
under these conditions.

Add `gdb-clang-incompatibility` to the `available_features` in
`cross-project-tests/lit.cfg.py` when clang's default DWARF version is 5 or
greater and the gdb (if found) version is less than 10.1.

Discourse discussion:
https://llvm.discourse.group/t/gdb-10-1-cant-read-clangs-dwarf-v5/6035

Reviewed By: jmorse

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

Not quite NFC because a little work was required to configure some tests to run
on Windows at all.

Before this patch on Windows:

    $ llvm-lit cross-project-tests\debuginfo-tests\dexter\feature-tests
       Unsupported: 49
       Passed     : 23

After this patch on Windows:

    $ llvm-lit cross-project-tests\debuginfo-tests\dexter\feature-tests
       Unsupported      : 27
       Passed           : 39
       Expectedly failed:  6

There are 3 main changes here. The first is to add a few more substitutions in
cross-project-tests/lit.cfg.py so that tests need to use specific flags can
still use the dexter regression test defaults for the native platform. These
are:

     %dexter_regression_test_debugger
     %dexter_regression_test_builder
     %dexter_regression_test_cflags
     %dexter_regression_test_ldflags

Tests that now use these options and therefore can be run on Windows too
(though the second is still failing for unknown reasons):

    cross-project-tests/debuginfo-tests/dexte/feature_tests
        /subtools/clang-opt-bisect/clang-opt-bisect.cpp
        /subtools/test/source-root-dir.cpp

The second change is to remove spurious `REQUIRES: system-linux, lldb` and
`UNSUPPORTED: system-windows` directives, and make changes to lit.local.cfg
files that have the same effect. I've also added comments to the genuine
REQUIRES, UNSUPPORTED, and XFAIL directives so it's easier to understand
requirements at a glance. The most common reason for a test to not be supported
on Windows is that it uses DexLimitSteps, DexDeclareAddress, or DexCommandLine,
none of which are supported in the dbgeng driver.

There are two failures on Windows that were previously hidden, which I've
XFAILed:

    cross-project-tests/debuginfo-tests/dexter/feature_tests
        /commands/perfect/dex_finish_test/default_conditional.cpp
        /commands/perfect/dex_finish_test/default_conditional_hit_count.cpp

And two that were easy to fix:

    cross-project-tests/debuginfo-tests/dexter/feature_tests
        /commands/perfect/dex_finish_test/default_simple.cpp
        /commands/perfect/dex_finish_test/default_hit_count.cpp

Lastly, I've set three directories as unsupported.

    cross-project-tests/debuginfo-tests/dexter/feature_tests
        /commands/perfect/limit_steps
        /commands/perfect/dex_declare_address
        /commands/perfect/dex_declare_file

The first two are unsupported on Windows because they contains tests for the
DexLimitSteps and DexDeclareAddress commands which aren't supported in the
dbgeng driver. The third is unsupported on all platforms as the tests involve
invoking clang directly, which isn't currently a supported way of building
tests for dexter in lit (it can cause problems for cross compilers that can
target the host, as the tests use the default triple and linker, which may
be aligned for the default target, not host).

Tested on Windows and Linux.

Reviewed By: jmorse

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

There have been a few API pieces remaining to allow for a smooth transition for
downstream users, but these have been up for a few months now. After this only
the C API will have reference to "Identifier", but those will be reworked in a followup.

The main updates are:
* Identifier -> StringAttr
* StringAttr::get requires the context as the first parameter
  - i.e. `Identifier::get("...", ctx)` -> `StringAttr::get(ctx, "...")`

Reviewed By: mehdi_amini

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

DexUnreachable is a useful tool for specifying that lines shouldn't be
stepped on. Right now they have to be placed in the source file; lets allow
them to be placed instead in a detached .dex file, by adding on_line and
line-range keyword arguments to the command.

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

This patch adds a "DexCommandLine" command, allowing dexter tests to
specify what command line options the test should be started with. I've
also plumbed it through into the debuggers.

This eases the matter of pointing Dexter at larger tests, or controlling
different paths through a single binary from a Dexter test.

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

- Prevent symbols from being stripped so that it can run with 'RelWithDebInfo'.
- Adjust llvm-support CHECKs after code changes.
- Polish mlir-support CHECKs as suggested in https://reviews.llvm.org/D116646.

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

Update prettyprinters.py to match MLIR changes.

This has gone unnoticed because no build bot is running tests with debug info.

I will look into what we can do about this separately. There is
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/,
from Apple. The Debug Info tests are failing despite the green result.

See https://github.com/llvm/llvm-project/issues/48872.

Note: the llvm-support.gdb test only works with Debug,
but not RelWithDebInfo because some checked symbols are stripped.

Reviewed By: dblaikie

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

Improves llvm-dwarfdump output and for simplified template names roundtripping.

This is just fixing the build itself, the test won't pass right now.

Currently, lld is marked as a dependency on Windows in
cross-project-tests/CMakeLists.txt which means CMake will fail if lld isn't
enabled. The idea of the cross-project-tests is that tests that don't have
their dependencies met should just be unsupported.

Remove the depenency from the CMake step and check whether Dexter's
platform-specific dependencies have been met in
cross-project-tests/lit.cfg.py. If the dependencies are met then add 'dexter'
to the available_features, otherwise don't and the dexter tests will be
"UNSUPPORTED".

Reviewed By: jhenderson

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

These tests were spuriously failing on Windows due to path separators getting
flipped from `/` to `\\`  in various parts of dexter:

test_add_breakpoint_with_source_root_dir
test_get_step_info
test_get_step_info_no_source_root_dir

Tested on Windows and Linux.

Patch written by @TWeaver.

Reviewed By: jmorse

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

Fixes a failure on the llvm-clang-x86_64-sie-ubuntu-fast buildbot caused
by the test requiring lldb (with the standard dexter lit config), but
not including a "Requires: lldb" clause.

This patch adds a new dexter command, DexDeclareAddress, which is used
to test the relative values of pointer variables. The motivation for
adding this command is to allow meaningful assertions to be made about
pointers that go beyond checking variable availability and null
equality.

The full explanation and syntax is in Commands.md.

Reviewed By: Orlando

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

[NFC] As part of using inclusive language within the llvm project, this patch
replaces master with controller in these tests.

Reviewed By: rjmccall

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

This handles DWARFv4 and DWARFv5 type units, but not Split DWARF type
units. That'll come in a follow-up patch.

Matching a recent clang change I've made, now 'int[3]' is formatted
without the space between the type and array bound. This commit updates
libDebugInfoDWARF/llvm-dwarfdump to match that formatting.

Actually we can, for now, remove the explicit "operator" handling
entirely - since clang currently won't try to flag any of these as
rebuildable. That seems like a reasonable state for now, but it could be
narrowed down to only apply to conversion operators, most likely - but
would need more nuance for op> and op>> since they would be incorrectly
flagged as already having their template arguments (due to the trailing
'>').

This isn't perfect, since it doesn't use lazy_string - so if the
std::string does contain unprintable characters it might fail, but seems
better than nothing & LLVM doesn't generally store binary data in
std::strings.

Still some pending bugs, but at least ironed some things out.

I'm not sure if there's a way to make this a bit more general - the
property that matters is that there's /some/ itanium ABI target the
tests can use to compile - not link or run in this case. But this seems
sufficient for the llgdb tests, so it should be sufficient (though
perhaps not necessary) for this roundtrip test.

Compilation is all that's needed here - linking helped avoid certain
false positives in llvm-dwarfdump --verify related to overlapping
functions when those functions were actually in distinct sections.
That's since been fixed, so we can adjust the test to only compile, and
not link.

Test is failing for unknown reasons and needs investigating.

This test was failing on the PS4 bot because the test attempts to link, but the PS4 platform requires an external
linker that is not present, causing the test to fail. This should get the PS4 bot green again.