================
@@ -1296,10 +1296,11 @@ enum CompletionType {
eRemoteDiskFileCompletion = (1u << 22),
eRemoteDiskDirectoryCompletion = (1u << 23),
eTypeCategoryNameCompletion = (1u << 24),
+ eThreadIDCompletion = (1u << 25),
----------------
jimingham wrote:
Even though this was a public enum, there was never anything you could do with
it from the SB API's. The only place you could set completions at all from the
outside was in `command script add` and that didn't use the enum values, it
used string equivalents.
So I think at this point we can change it as we need.
We also don't add completions that extend this table anywhere in lldb that I
can see, we use custom completion functions that we use by hand in the
HandleCompletion's instead. And anyway, all that is internal to lldb_private,
that's not exposed.
So I think none of this is really designed or used at this point, and we should
think of what we want to do with this.
I think eCustomCompletion should mean "this object implements a custom
completion, use that instead of any of the built-in ones." So overloading it
to be the enum terminator is wrong, since its value cannot float, it has to
have a definite meaning.
The terminator is useful for input validation. The "parsed command" patch I'm
working on WILL allow users to specify a completion for the arguments, and it
would be useful to be able to say "that enum value you just passed me was out
of the range of valid completions." But I think that's all it's needed for.
So I'd suggest leaving eCustomCompletion where it is, adding the Thread ID one
after and then adding a terminator for input validation.
https://github.com/llvm/llvm-project/pull/73596
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
