-
Notifications
You must be signed in to change notification settings - Fork 403
Open
Description
I'm tracking down a weird regression coming from 1.18.2 to 1.24.0.
UseCorrectCasing reports that if enabled, operators will be set to their "lowercase" format. But treatment of operators seems different, particularly within expressions.
Steps to reproduce
'@{ Rules = @{ PSUseCorrectCasing = @{ Enable = $true } } }' > rules.psd1
$scriptDefinition = @'
if ($name -EQ 'foo')
{
Write-Message "hi"
}
$coll = @()
$coll += [pscustomobject]@{
Name = 'bar'
}
if (-not ($coll | Where-Object Name -eq 'bar'))
{
Write-Message "hi!"
}
'@
Invoke-ScriptAnalyzer -Settings rules.psd1 -ScriptDefinition $scriptDefinitionExpected behavior
Line 1 should be switched to -eq
Line 9 should stay as -eq
Actual behavior
RuleName Severity ScriptName Line Message
-------- -------- ---------- ---- -------
PSUseCorrectCasing Information 1 Operator '-EQ' does not match the expected case '-eq'.
PSUseCorrectCasing Information 9 Function/Cmdlet '-eq' does not match its exact casing 'EQ'.
The devil may be in the details, but why one operator (line 1) is detected as "an operator" while the one on line 9 is detected as a "Function/CmdLet" ?
Environment data
> $PSVersionTable
Name Value
---- -----
PSVersion 7.5.3
PSEdition Core
GitCommitId 7.5.3
OS Microsoft Windows 10.0.26200
Platform Win32NT
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.24.0potatoqualitee
Metadata
Metadata
Assignees
Labels
No labels