Invoke-ScriptAnalyzer : 'count' must be non-negative.

[KyleMartin901]

I get the error Invoke-ScriptAnalyzer : 'count' must be non-negative. when I have the setting PSAlignAssignmentStatement enabled for CheckHashTable and a hash is on the same line rather then a new line. If CheckHashTable is set to false there is no error.

Steps to reproduce

I have created a sample project that can be used to reproduce the error at https://github.com/KyleMartin901/km-psscript

Expected behavior

Actual behavior

Invoke-ScriptAnalyzer : 'count' must be non-negative.
Parameter name: count
At line:1 char:1
+ Invoke-ScriptAnalyzer -Path Test-Func.ps1 -Settings psscriptanalyzers ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (/temp/scripts/Test-Func.ps1:String)[Invoke-ScriptAnalyzer], ArgumentOutOfRangeException
+ FullyQualifiedErrorId : RULE_ERROR,Microsoft.Windows.PowerShell.ScriptAnalyzer.Commands.InvokeScriptAnalyzerCommand

If an unexpected error was thrown then please report the full error details using e.g. $error[0] | Select-Object *

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.0.4
PSEdition                      Core
GitCommitId                    v6.0.4
OS                             Linux 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16...
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
> (Get-Module -ListAvailable PSScriptAnalyzer).Version | ForEach-Object { $_.ToString() }
1.17.1

[bergmeister]

Thanks for the detailed submission. I can confirm this happens also for Windows PowerShell 5.1 and I could catch the exception, the problem lies in the 2nd argument to the constructor of the string that results in a negative number (20-28=-8)

The underlying problem is this code line here that determines the extent with the widest equal sign only by looking at the length of tje key. This calculation goes wrong in this line here where ProductSlug is more to the right than DownloadPath.
I have a preliminary fix in my branch here and will issue a PR tomorrow (see below)