After parsing blocks in a function, the blocks should be marked as
parsed for them to be dumped (see
[Function::Dump](https://github.com/llvm/llvm-project/blob/e6aefbec782dbb57f72eb0ae399ed944fe49db2e/lldb/source/Symbol/Function.cpp#L446-L447)).
As explained in
https://github.com/llvm/llvm-project/issues/114906#issuecomment-3255016266,
this happens (accidentally?) in the DIA plugin when parsing variables,
because it calls `function.GetBlock(can_create=true)` which marks blocks
as parsed. In the native plugin, this was never called, so blocks and
variables were never included in the `lldb-test symbols` output.

The `variables.test` for the DIA plugin tests this. One difference
between the plugins is how they specify the location of local variables.
This causes the output of the native plugin to be two lines per
variable, whereas the DIA plugin has one line:
```
(native):
000002C4B7593020:       Variable{0x1c800001}, name = "var_arg1", type = {0000000000000744} 0x000002C4B6CA7900 (int), scope = parameter, location = 0x00000000:
        [0x000000014000102c, 0x000000014000103e): DW_OP_breg7 RSP+8
```
```
(DIA):
000002778C827EE0:       Variable{0x0000001b}, name = "var_arg1", type = {0000000000000005} 0x000002778C1FBAB0 (int), scope = parameter, decl = VariablesTest.cpp:32, location = DW_OP_breg7 RSP+8
```
In the test, I filtered lines starting with spaces followed by `[0x`, so
we can still use `CHECK-NEXT`.

---

Another difference between the plugins is that DIA marks the `this`
pointer as artificial (equivalent to DWARF). This is done if a
variable's object kind is `ObjectPtr`
([source](https://github.com/llvm/llvm-project/blob/ab898f32c60689d1d47d0b6de66c30d3476994bb/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp#L1050)).
As far as I know, there isn't anything in the debug info that says "this
variable is the `this` pointer" other than the name/type of a variable
and the type of the function.

To find global variables, `SymbolFileNativePDB` used to search the
globals stream for the name passed to `FindGlobalVariables`. However,
the symbols in the globals stream contain the fully qualified name and
`FindGlobalVariables` only gets the basename. The approach here is
similar to the one for types and functions.

As we already search the globals stream for functions, we can cache the
basenames for global variables there as well.

This makes the `expressions.test` from the DIA PDB plugin pass with the
native one (#114906).

https://github.com/llvm/llvm-project/pull/153160 created those function
maps and uses default sort comparator which is not deterministic when
there are multiple entries with same name because llvm::sort is unstable
sort.

This fixes it by comparing the id value when tie happens and sort
`m_type_base_names` deterministically as well.

Some functions don't have the `FunctionType` set. We can't look these up
and won't be able to call them, so ignore them when caching the function
names.

This does fix the failures caused by
https://github.com/llvm/llvm-project/pull/153160 mentioned in
https://github.com/llvm/llvm-project/pull/153160#issuecomment-3183062431.
However, in `lldb-shell::msstl_smoke.cpp` there's another failure not
introduced by #153160 (fixed with #153386).

This patch fixes:

  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:647:3:
  error: 'llvm::Expected' may not intend to support class template
  argument deduction [-Werror,-Wctad-maybe-unsupported]

  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:677:3:
  error: 'llvm::Expected' may not intend to support class template
  argument deduction [-Werror,-Wctad-maybe-unsupported]

Tag types like stucts or enums didn't have a declaration attached to
them. The source locations are present in the IPI stream in
`LF_UDT_MOD_SRC_LINE` records:

```
   0x101F | LF_UDT_MOD_SRC_LINE [size = 18, hash = 0x1C63]
            udt = 0x1058, mod = 3, file = 1, line = 0
   0x2789 | LF_UDT_MOD_SRC_LINE [size = 18, hash = 0x1E5A]
            udt = 0x1253, mod = 35, file = 93, line = 17069
```

The file is an ID in the string table `/names`:

```
     ID | String
      1 | '\<unknown>'
     12 | 'D:\a\_work\1\s\src\ExternalAPIs\WindowsSDKInc\c\Include\10.0.22621.0\um\wingdi.h'
     93 | 'D:\a\_work\1\s\src\ExternalAPIs\WindowsSDKInc\c\Include\10.0.22621.0\um\winnt.h'
```

Here, we're not interested in `mod`. This would indicate which module
contributed the UDT.

I was looking at Rustc's PDB and found that it uses `<unknown>` for some
types, so I added a check for that.

This makes two DIA PDB shell tests to work with the native PDB plugin.

---------

Co-authored-by: Michael Buch <michaelbuch12@gmail.com>

Relands #152295.

Checking for the overloads did not account for them being out of order.
For example, [the failed
output](https://github.com/llvm/llvm-project/pull/152295#issuecomment-3177563247)
contained the overloads, but out of order. The last commit here fixes
that by using `-DAG`.

---------

Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>

Reverts llvm/llvm-project#152295

This adds the ability for functions to be matched by their basename.

Before, the globals were searched for the name. This works if the full
name is available but fails for basenames.
PDB only includes the full names of functions, so we need to cache all
basenames. This is (again) very similar to
[SymbolFilePDB](https://github.com/llvm/llvm-project/blob/b242150b075a8a720b00821682a9469258bbcd30/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp#L1291-L1383).
There are two main differences:

- We can't just access the parent of a function to determine that it's a
member function - we need to check the type of the function, and its
"this type".
- SymbolFilePDB saved the full method name in the map. However, when
searching for methods, only the basename is passed, so the function
never found any methods.

Fixes #51933.

---------

Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>