# Summary
`SBFileSpec::GetPath(char *dst_path, size_t dst_len)` contains `char*`
type argument. Need to handle this for python. Fortunately there're
already similar definitions we can reuse.

# Test Plan
Start the freshly built lldb and run the following code
```
$ lldb
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> debugger = lldb.SBDebugger.Create()
>>> debugger.SetAsync (False)
>>> target = debugger.CreateTarget("~/tmp/hello")
>>> target.IsValid()
True
>>> breakpoint = target.BreakpointCreateByName('main', 'hello')
>>> breakpoint.GetNumLocations()
1
>>> process = target.LaunchSimple (None, None, os.getcwd())
>>> process.IsValid()
True
>>> thread = process.GetThreadAtIndex(0)
>>> frame = thread.GetFrameAtIndex(0)
>>> line = frame.GetLineEntry()

# Important line below
>>> file = line.GetFileSpec().GetPath(1024)
# Important line above

>>> print(file)
/home/wanyi/tmp/main.cpp
```

## Before this change
```
$ lldb
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> debugger = lldb.SBDebugger.Create()
>>> debugger.SetAsync (False)
>>> target = debugger.CreateTarget("~/tmp/hello")
>>> target.IsValid()
True
>>> breakpoint = target.BreakpointCreateByName('main', 'hello')
>>> breakpoint.GetNumLocations()
1
>>> process = target.LaunchSimple (None, None, os.getcwd())
>>> process.IsValid()
True
>>> thread = process.GetThreadAtIndex(0)
>>> frame = thread.GetFrameAtIndex(0)
>>> line = frame.GetLineEntry()
>>> file = line.GetFileSpec().GetPath(1024)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: SBFileSpec.GetPath() missing 1 required positional argument: 'dst_len'
>>> print(file)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
NameError: name 'file' is not defined
```

When we take the following C program:
```
int main() {
  return 0;
}
```
and create a statically-linked executable from it:
```
clang -static -g -o main main.c
```
Then we can observe the following `lldb` behavior:
```
$ lldb
(lldb) target create main
Current executable set to '.../main' (x86_64).
(lldb) breakpoint set --name main
Breakpoint 1: where = main`main + 11 at main.c:2:3, address = 0x000000000022aa7b
(lldb) process launch
Process 3773637 launched: '/home/me/tmp/built-in/main' (x86_64)
Process 3773637 stopped
* thread #1, name = 'main', stop reason = breakpoint 1.1
    frame #0: 0x000000000022aa7b main`main at main.c:2:3
   1   	int main() {
-> 2   	  return 0;
   3   	}
(lldb) script lldb.debugger.GetSelectedTarget().FindFirstType("__int128").size
0
(lldb) script lldb.debugger.GetSelectedTarget().FindFirstType("unsigned __int128").size
0
(lldb) quit
```
The value return by the `SBTarget::FindFirstType` method is wrong for
the `__int128` and `unsigned __int128` basic types.

The proposed changes make the `TypeSystemClang::GetBasicTypeEnumeration`
method consistent with `gcc` and `clang` C [language
extension](https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html)
related to 128-bit integer types as well as with the
`BuiltinType::getName` method in the LLVM codebase itself.

When the above change is applied, the behavior of the `lldb` changes in
the following (desired) way:
```
$ lldb
(lldb) target create main
Current executable set to '.../main' (x86_64).
(lldb) breakpoint set --name main
Breakpoint 1: where = main`main + 11 at main.c:2:3, address = 0x000000000022aa7b
(lldb) process launch
Process 3773637 launched: '/home/me/tmp/built-in/main' (x86_64)
Process 3773637 stopped
* thread #1, name = 'main', stop reason = breakpoint 1.1
    frame #0: 0x000000000022aa7b main`main at main.c:2:3
   1   	int main() {
-> 2   	  return 0;
   3   	}
(lldb) script lldb.debugger.GetSelectedTarget().FindFirstType("__int128").size
16
(lldb) script lldb.debugger.GetSelectedTarget().FindFirstType("unsigned __int128").size
16
(lldb) quit
```

---------

Co-authored-by: Matej Košík <matej.kosik@codasip.com>

Depends on:
* https://github.com/llvm/llvm-project/pull/162050

Since it's a 'Note' diagnostic it would only show up when expression
evaluation actually failed. This helps with expression evaluation
failure reports in mixed language environments where it's not quite
clear what language the expression ran as. It may also reduce confusion
around why the expression evaluator ran an expression in a language it
wasn't asked to run (a softer alternative to what I attempted in
https://github.com/llvm/llvm-project/pull/156648).

Here are some example outputs:
```
# Without target
(lldb) expr blah
note: Falling back to default language. Ran expression as 'Objective C++'.

# Stopped in target
(lldb) expr blah
note: Ran expression as 'C++14'.

(lldb) expr -l objc -- blah
note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'.

(lldb) expr -l c -- blah
note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'.

(lldb) expr -l c++14 -- blah
note: Ran expression as 'C++14'

(lldb) expr -l c++20 -- blah
note: Ran expression as 'C++20'

(lldb) expr -l objective-c++ -- blah
note: Ran expression as 'Objective C++'

(lldb) expr -l D -- blah
note: Expression evaluation in D not supported. Falling back to default language. Ran expression as 'Objective C++'.
```

I didn't put the diagnostic on the same line as the inline diagnostic
for now because of implementation convenience, but if reviewers deem
that a blocker I can take a stab at that again.

Also, other language plugins (namely Swift), won't immediately benefit
from this and will have to emit their own diagnistc. I played around
with having a virtual API on `UserExpression` or `ExpressionParser` that
will be called consistently, but by the time we're about to parse the
expression we are already several frames deep into the plugin. Before
(and at the beginning of) the generic `UserExpression::Parse` call we
don't have enough information to notify which language we're going to
parse in (at least for the C++ plugin).

rdar://160297649
rdar://159669244

### Summary
Add support for unique target ids per Target instance. This is needed
for upcoming changes to allow debugger instances to be shared across
separate DAP instances for child process debugging. We want the IDE to
be able to attach to existing targets in an already runny lldb-dap
session, and having a unique ID per target would make that easier.

Each Target instance will have its own unique id, and uses a
function-local counter in `TargetList::CreateTargetInternal` to assign
incremental unique ids.

### Tests
Added several unit tests to test basic functionality, uniqueness of
targets, and target deletion doesn't affect the uniqueness.
```
bin/lldb-dotest -p TestDebuggerAPI
```

The LLVM Style Guide says the following about error and warning messages
[1]:

> [T]o match error message styles commonly produced by other tools,
> start the first sentence with a lowercase letter, and finish the last
> sentence without a period, if it would end in one otherwise.

I often provide this feedback during code review, but we still have a
bunch of places where we have inconsistent error message, which bothers
me as a user. This PR identifies a handful of those places and updates
the messages to be consistent.

[1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages

* Adds `dynamic` property to automatically convert `SBStructuredData`
instances to the associated Python type (`str`, `int`, `float`, `bool`,
`NoneType`, etc)
* Implements `__getitem__` for Pythonic array and dictionary
subscripting
  * Subscripting return the result of the `dynamic` property
* Updates `__iter__` to support dictionary instances (supporting `for`
loops)
* Adds `__str__`, `__int__`, and `__float__`

With these changes, these two expressions are equal:

```py
data["name"] == data.GetValueForKey("name").GetStringValue(1024)
```

**Note**: Unlike the original commit (#155061), this re-commit removes
the `__bool__` implementation, which broke crashlog. Somewhere in the
crashlog execution, it depends on `__bool__` meaning only `IsValid()`.

Additionally did some cleanup in TestStructuredDataAPI.py.

TestGetBaseName.py is currently marked as an expected failure on Windows
because SBFunction::GetBaseName() and SBSymbol::GetBaseName() don’t yet
handle MSVC-style mangling.

This patch updates the @expectedFailureAll decorator to include a
reference to https://github.com/llvm/llvm-project/issues/156861

Reverts #155061 (and #156721) which caused Crashlog shell tests to break.

`__str__` was implemented in #155061, however its behavior was limited
to only a some kinds of `SBStructuredData`. That was a breaking change,
and this change removes that implementation of `__str__`, relying on the
existing behavior which calls `GetDescription`.

* Adds `dynamic` property to automatically convert `SBStructuredData`
instances to the associated Python type (`str`, `int`, `float`, `bool`,
`NoneType`, etc)
* Implements `__getitem__` for Pythonic array and dictionary
subscripting
  * Subscripting return the result of the `dynamic` property
* Updates `__iter__` to support dictionary instances (supporting `for`
loops)
* Adds conversion to `str`, `int`, and `float`
* Adds Pythonic `bool` conversion

With these changes, these two expressions are equal:

```py
data["name"] == data.GetValueForKey("name").GetStringValue(1024)
```

Additionally did some cleanup in TestStructuredDataAPI.py.