================ @@ -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