Depends on:
* https://github.com/llvm/llvm-project/pull/187229
(only second commit and onwards are relevant)
This patch implements the base infrastructure described in this [RFC re.
Moving libc++ data-formatters out of
LLDB](https://discourse.llvm.org/t/rfc-lldb-moving-libc-data-formatters-out-of-lldb/89591)
The intention is to provide vendors with a way to pre-configure a set of
paths that LLDB can automatically ingest formatter scripts from.
Three main changes:
1. Adds a CMake variable `LLDB_SAFE_AUTO_LOAD_PATHS` which is a
semi-colon separated list of paths. This is intended to be set by
vendors when building LLDB for distribution.
2. Adds a setting that only exists in asserts mode called
`testing.safe-auto-load-paths` which allows setting the paths without a
CMake configuration. Used for local development and, more crucially, the
shell and unit tests
3. Adds a `LocateScriptingResourcesFromSafePaths` which
`Platform::LocateExecutableScriptingResources` calls by default (and
hence used by all platforms). I add a
`LocateExecutableScriptingResourcesImpl` that platforms can override if
they have platform-specific resource script locations (e.g., dSYMs on
Darwin).
Whenever we load an image, we check the safe path (starting with the
last appended path) for a directory called
`/safe/path/to/<module>/<module>.py`. If such script exists, we import
it as a Python module. If not, we move on to the next safe path.
Currently the default for `LLDB_SAFE_AUTO_LOAD_PATHS` is empty.
Eventually the plan is to make those point to the libc++ installation
(where the formatters will live) depending on platform/vendor. For macOS
we'll add a special `$SDK_ROOT` that can be used in the path variable,
which `LocateScriptingResourcesFromSafePaths` will resolve to an actual
SDK path.
*AI Usage*:
* Claude assisted with the CMake machinery which I then reviewed and
cleaned up. I'm not sure this is the most idiomatic way of letting a
user provide lists of paths, but I couldn't find a better way.
* Wrote the basic auto-load Shell tests myself and asked claude to stamp
out a bunch more for different scenarios. Reviewed and cleaned those up
myself.
This patch makes the warning message more concise (in my opinion). We
would duplicate the file path multiple times in the message. I'm
planning on factoring this logic into a standalone function, and having
it rely on fewer parameters helps with that.
Before:
```
warning: the symbol file '/path/to/.dSYM/Contents/Resources/DWARF/import' contains a debug script.
However, its name '/path/to/.dSYM/Contents/Resources/DWARF/../Python/import.py' conflicts with a keyword
and as such cannot be loaded. LLDB will load '/path/to/.dSYM/Contents/Resources/DWARF/../Python/_import.py' instead.
Consider removing the file with the malformed name to eliminate this warning.
```
After:
```
warning: debug script '/path/to/.dSYM/Contents/Resources/DWARF/../Python/import.py' cannot be loaded
because 'import.py' conflicts with the keyword 'import'. Ignoring 'import.py' and loading '_import.py' instead.
```
Before:
```
warning: the symbol file '/path/to/.dSYM/Contents/Resources/DWARF/import' contains a debug script.
However, its name conflicts with a keyword and as such cannot be loaded.
If you intend to have this script loaded, please rename '/path/to/.dSYM/Contents/Resources/DWARF/../Python/import.py'
to '/path/to/.dSYM/Contents/Resources/DWARF/../Python/_import.py' and retry.
```
After:
```
warning: debug script '/path/to/.dSYM/Contents/Resources/DWARF/../Python/import.py' cannot be loaded
because 'import.py' conflicts with the keyword 'import'. If you intend to have this script loaded, please rename
it to '_import.py' and retry.
```
I'm in the process of making `LoadScriptingResources` interactively ask
a user whether to load a script. I'd like to turn the existing warning
into the prompt. The simplest way to achieve this is to not print into a
`feedback_stream` parameter, and instead create a prompt right there.
This patch removes the `feedback_stream` parameter and emits a
`ReportWarning` instead. If we get around to adding the prompt instead
of the warning, those changes will be simpler to review. But even if we
don't end up replacing the warning with a prompt, moving away from
output parameters and towards more structured error reporting is a
nice-to-have (e.g., the `warning` prefix is now colored, IDEs have more
flexibility on how to present the warning, etc.).
For a command-line user nothing should change with this patch (apart
from `warning:` being highlighted).
Makes it obvious what the warning will look like (with the indenentation
etc.). Also adds a test since we had no coverage for the warning before
(as far as I'm aware).
