================
@@ -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
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to