User Details
- User Since
- Aug 14 2015, 10:30 PM (283 w, 1 d)
Thu, Jan 7
Dec 8 2020
Dec 7 2020
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.
Nov 20 2020
Minor rewording
Nov 19 2020
But those functions don't have any error handling, so not a lot we can do about this in the meantime.
Nov 18 2020
The purpose and the tests LGTM! Hopefully someone will weigh in on the implementation in ContinuationIndenter.cpp.
Nov 11 2020
Remove bogus message.
Thanks for pointing this in the right direction @labath, @teemperor.
Nov 10 2020
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?
Nov 6 2020
Nov 5 2020
Oct 26 2020
thanks for correcting my misunderstanding
Oct 19 2020
Oct 17 2020
Oct 16 2020
Name suggestion: -prepend_rpath or -insert_initial_rpath. By itself, "insert" feels like it should take a position to say where it insert.
Oct 14 2020
Reverted here: 4cb4db11ee1323c5d4bf66d21deb046970f4e516
@martong here's a partial backtrace:
@martong hi, this caused a test regression. In TestImportBuiltinFileID.py, this unreachable assertion is hit:
Oct 13 2020
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.
Thanks
Oct 12 2020
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.
Oct 7 2020
Update commit message
@teemperor I removed the comment and restored repository handling. It becomes much more of a useless diff :)
Restore repository handling
Oct 6 2020
switch NULL to ""
Unbreak code
Oct 5 2020
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
Oct 3 2020
Sep 30 2020
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".
Sep 29 2020
Sep 24 2020
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.
Sep 23 2020
sgtm