ArgumentOutOfRangeException: Completion of Splat, but Not $

[msftrncs]

Using a custom build of PS 7 Preview, but also applies to 5.1 and 6/6.1/6.2 in the right conditions.

I have been working with the PowerShell code to try to get completion starting at a splat @ to work. With that working, the current completion code completes the $ variable as @{$}, which is knowingly invalid, and it causes an ArgumentOutOfRange exception.

Steps to reproduce or exception report

This reproduction is for the released builds of PowerShell, as they will not currently produce completions for just a @ argument.

Complete the following:

echo @?<CTRL SPACE> # crashes after list is displayed, but before the first result is inserted
echo $<CTRL SPACE> # notice selection varies with variable names that require a brace

Note, the window must be large enough as to be able to display the entire list without the input line scrolling off the top. Also, I've only tested this in Windows.

Code in Question

I traced down the code that is calling the exception:

PSReadLine/PSReadLine/Completion.cs

Lines 732 to 737 in b7b8f7b

	private int FindUserCompletionTextPosition(CompletionResult match, string userCompletionText)
	{
	return match.ResultType == CompletionResultType.Variable && match.CompletionText[1] == '{'
	? match.CompletionText.IndexOf(userCompletionText.Substring(1), StringComparison.OrdinalIgnoreCase) - 1
	: match.CompletionText.IndexOf(userCompletionText, StringComparison.OrdinalIgnoreCase);
	}

I think the check for a { is incorrect here, and that there is no reason to ever substring the original text, removing the prefix, which causes the completion to look like its replacing the prefix as well.

[msftrncs]

I'm also pretty sure there is some code somewhere else dealing specifically with the @ condition, and its not just the linked to function above that's at problem, because, why else would it exist.

[msftrncs]

Also reported at PowerShell/PowerShell#10243

[msftrncs]

I think the error is here:

PSReadLine/PSReadLine/Completion.cs

Lines 102 to 114 in b7b8f7b

	private static string GetUnquotedText(CompletionResult match, bool consistentQuoting)
	{
	var s = match.CompletionText;
	if (match.ResultType == CompletionResultType.Variable)
	{
	if (IsQuotedVariable(s))
	{
	return '$' + s.Substring(2, s.Length - 3);
	}
	return s;
	}
	return GetUnquotedText(s, consistentQuoting);
	}

The CompletionResultType is Variable for a splat, and so PSReadLine for some reason is tearing off the braces, but while doing so changes the @ to a $, and then later attempts to compare that with each completion to see how much of the command its completing for highlighting purposes, but since the @ is now a $, the comparison determines that no text changes (or stays the same or whatever), which results in an empty string which then ends up as the userCompletionText in FindUserCompletionTextPosition which because the second character of the match.CompletionText is a '{' results in a substring(1) of an empty string, ArgumentOutOfRangeException.

[daxian-dbw]

echo @? # crashes after list is displayed, but before the first result is inserted
echo $ # notice selection varies with variable names that require a brace

@msftrncs I cannot repro the crash with these steps. I'm using 7.0-preview.1 (see the screen gif below).
Does the console buffer size need to be somehow configured to repro this?

[msftrncs]

@daxian-dbw, yes, the buffer needs enough lines visible so that the list can populate without the input line scrolling off the top, so that the first item in the list can replace the current input.

[daxian-dbw]

yes, the buffer needs enough lines visible so that the list can populate without the input line scrolling off the top, so that the first item in the list can replace the current input.

Thanks, that helps. I can repro the issue now.

[msftrncs]

I think I forgot to include that echo @?<TAB> is also a quick way to produce the error, as long as the first completion returned is the typical @{$}.

oops, guess it doesn't, that works...

[msftrncs]

I think I figured out what the check for a { is doing …

The detection for a { appears to be to handle the situation where @en is the input, and then when @{env:blah(blah)} is the completion, the selection becomes 'v:blah(blah)}`, preventing the matching process from selecting from the first brace.

[daxian-dbw]

@msftrncs I can reproduce the crash using echo @?<CTRL SPACE>, but not exactly sure what you mean with the second repro echo $<CTRL SPACE>.

# notice selection varies with variable names that require a brace

The selection looks fine to me for variables that require a brace. Can you please clarify it a bit more?

[msftrncs]

echo $<CTRL SPACE> # notice selection varies with variable names that require a brace

The selection looks fine to me for variables that require a brace. Can you please clarify it a bit more?

Hopefully these snips clarify the comment, but because it could be said better: 'the selection of the leading $ varies depending on whether the variable name requires a brace, or not.'

Because the $ sigil is there in all cases, it should not be part of the selection. The fix in PR #984 acts like this:

[daxian-dbw]

Thanks for the further clarification. You really have a pair of sharp eyes to find this inconsistency 😄