`PSPossibleIncorrectUsageOfAssignmentOperator` fires when assigning value inside `if($())`

[o-l-a-v]

Before submitting a bug report:

• Make sure you are able to repro it on the latest released version
• Perform a quick search for existing issues to check if this bug has already been reported

Steps to reproduce

Invoke-ScriptAnalyzer -ScriptDefinition (
    [scriptblock]::Create{
        if (
            [bool]$(Try{$null=[datetime]('2024-11-12T09:44:00Z');$?}Catch{$false})
        ) {
            Write-Output -InputObject 'Could be parsed as datetime'
        }
        else {
            Write-Output -InputObject 'Could not be parsed as datetime'
        }
    }.ToString()
) -IncludeRule 'PSPossibleIncorrectUsageOfAssignmentOperator' | Format-List

Expected behavior

Actual behavior

RuleName : PSPossibleIncorrectUsageOfAssignmentOperator
Severity : Warning
Line     : 3
Column   : 30
Message  : Did you mean to use the assignment operator '='? The equality operator in PowerShell is 'eq'.

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

Environment data

PS > $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.4.6
PSEdition                      Core
GitCommitId                    7.4.6
OS                             Microsoft Windows 10.0.26100
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS > (Get-Module -ListAvailable PSScriptAnalyzer).Version | ForEach-Object { $_.ToString() }

1.23.0

PS >

[bergmeister]

This is how the rule works by design. We do not know if author intended to do $null -eq $foo or $null = $foo, hence the word Possible. It's to alert the author to double check and confirm with suppression that assignment inside if was by design. There was a lengthy discussion about this in the PR that added this rule but it boils down to the rule being useful, which always comes with false positives and user can decide whether they'd prefer to suppress to confirm intention in code or not use this rule as such pattern like yours is more used by advanced users. Having said that I added this rule because I myself quite often made that mistake especially when switching between PS and C# that I used = when I actually meant to write =