Yes I plan to merge this manually (rather than automerge) to ensure it's not disruptive.

Remove function use of is_variadic_ptr

I can't read.

Minor rewording

But those functions don't have any error handling, so not a lot we can do about this in the meantime.

The purpose and the tests LGTM! Hopefully someone will weigh in on the implementation in ContinuationIndenter.cpp.

Remove bogus message.

Thanks for pointing this in the right direction @labath, @teemperor.

That's much better. I'll change those callers can be changed to runCmd.

@teemperor maybe? Do you mean validation should go in runCmd? Or do you mean something else?

thanks for correcting my misunderstanding

Name suggestion: -prepend_rpath or -insert_initial_rpath. By itself, "insert" feels like it should take a position to say where it insert.

Reverted here: 4cb4db11ee1323c5d4bf66d21deb046970f4e516

@martong here's a partial backtrace:

@martong hi, this caused a test regression. In TestImportBuiltinFileID.py, this unreachable assertion is hit:

Use type INTERNAL

else/if -> elseif

This doesn't require a ld64 version check, and it's a much less invasive cmake change.

Would you mind adding a couple tests for imports via a path to a python file, ex command script import command.py, maybe even a test that checks nested directories, ex: command script import path/to/command.py?

I don't think it's that unreasonable to do the same for $HOME to be able to use imports relative to the .lldbinit file in both cases.

(and whether we should make this implicit a relative path vs for example some kind of placeholder 'variable' or something like that).

For lldbinit files, and any file that gets command source'd, I think it would be useful if they could perform command script import some/path/to/command.py, where some is resolved relative to the dirname of the lldb file. For example, given an lldbinit file at my/project/scripts/project.lldb, it could load a python at my/project/scripts/commands/my.py by running command script import commands/my.py.

In D89295#2327367, @labath wrote:

That actually seems to work (if you add .py to the end).

Thanks

Could this have undesirable side effects? I wouldn't expect command script import to be searching my home dir. Second question: is there value in requiring the explicit use of ~, for ex: command script import ~/path.

Update commit message

@teemperor I removed the comment and restored repository handling. It becomes much more of a useless diff :)

Restore repository handling

switch NULL to ""

Unbreak code

About -P, the man page for lldb and the driver's Options.td say it:

"missing a matcher" -> "missing a matcher argument"

Resyntax the isinstance asserts; Add expect() tests

I must have missed something, isn't this embedded the installed path of the clang resource dir? The diff description says "i.e., building just LLDB against an existing LLVM/Clang installation". I agree that embedding a build path is bad, but embedding clang's installed path seems legit.

Nice fix. Every time I see issues with the relative resource directory heuristic, I think "someone should improve that".

I agree it's nice to have somewhere, but git history should be fine. I should elaborate on motivations, 1. ensure everyone is using the script so that any issues are surfaced, 2. prevent missteps in the manual process, which may also be bit rotting if everyone is using the script.

sgtm