PR Summary

The constructor of CompletionResult doesn't allow an empty string argument. Exception will be thrown if an empty string is passed in.

For example, with an argument completer defined like this (or, use return $null):

register-ArgumentCompleter -Native -CommandName ping -ScriptBlock {
    param($WordToComplete, $CommandAst, $CursorPosition)
    return ''
}

You will get an exception when calling TabExpansion2 for ping:

PS:49> $result = TabExpansion2 -inputScript 'ping ' -cursorColumn 5
MethodInvocationException:
Line |
  40 |  …      return [System.Management.Automation.CommandCompletion]::Complet …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Exception calling "CompleteInput" with "3" argument(s): "Cannot process argument because the value of argument "completionText" is null. Change the value of argument "completionText" to a non-null value."

This PR improves how InvokeScriptArgumentCompleter handles the return values from a custom argument completer script block:

1. Avoid ArgumentException or NullReferenceException when the return values include null or empty string.
2. Today, when a custom completer returns $null or an empty string, due to the exception (which gets swallowed by PSReadLine), the user-perceived behavior is -- no result, and default completion (e.g. file names) is suppressed. So, it's not uncommon for developers to intentionally depend on this behavior suppress file name completion.
   • This behavior is explicitly preserved -- when a custom completer script block returns $null or empty string, the completion is considered successfully, and we will not fall back to default completions.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge. If this PR is a work in progress, please open this as a Draft Pull Request and mark it as Ready to Review when it is ready to merge.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed